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The  purpose  of  (he  Defense  Systems  Management  Review  is  to 
disseminate  information  concerning  new  developments  and  effec- 
tive actions  taken  relative  to  the  management  of  defense  systems 
programs  and  defense  systems  acquisition. 

The  Review  is  designed  as  a vehicle  to  transmit,  between  persons 
in  positions  of  leadership  and  responsibility  in  the  program 
management  and  systems  acquisition  communities,  information 
on  policies,  trends,  events  and  current  thinking  affecting  the 
practice  of  program  management  and  defense  systems  acquisi- 
tion. The  publication  serves  as  a means  for  providing  an  historical 
record  of  significant  information  associated  with  defense  systems 
acquisition/management  concepts  and  practices. 


The  Review  supports  the  assigned  mission  of  the  Defense  Systems 
Management  College,  and  serves  as  a medium  for  continuing  the 
education  and  professional  development  of  persons  in  the  field 


*7  I 

cmtiiJTiOH  lutiWr'tf  & 1 


lit*.  illH 


Review:  US  ISSN  0363-7727 


Defense  Systems  Management  Review 


DEFENSE  SYSTEMS 
MANAGEMENT  COLLEGE 


Dear  Reader: 


To  be  assured  that  the  articles  appearing  in  the  Defense  Systems 
Management  Review  are  timely,  current,  germane  and  of  highest 


■ 

h 

h 


quality,  we  will  have  several  of  the  very  eminent  practitioners-of-the- 
art  of  program  management  review  the  articles  that  are  presented  in 
future  issues.  These  individuals  will  be  identified  as  Associate  Editors 
and  will  serve  a very  important  function.  The  following  individuals 
have  agreed  to  serve  in  this  capacity: 

The  Honorable  Norman  Augustine 
Vice  President,  Technical  Operations 
Martin  Marietta  Aerospace 

Mr.  John  M.  Malloy 

Vice  President,  Administration 

Teledyne  Ryan  Aeronautical 

LtGen  John  O’Neill,  USAF  (Ret) 

President 

Armed  Forces  Relief  and  Benefit  Association 

The  Honorable  Leonard  Sullivan,  Jr. 

Consultant 

Mr.  John  W.  Welch 
Vice  President  for  Programs 
Vought  Aeronautical  Division 
LTV  Aerospace  Corporation 

On  behalf  of  the  overall  systems  acquisition  community,  the  Defense 
Systems  Management  College  expresses  its  sincere  appreciation  to 
these  individuals. 

JOHN  G ALBERT 
Major  General,  US  Air  Force 
Commandant 


in 


Vol  I,  No  2. 


DEFENSE  SYSTEMS  MANAGEMENT 


REVIEW 


VOL  I,  NO  2.  SPRING  1977 


FOREWORD iii 

Major  General  John  G.  Albert,  USAF,  Commandant 

ELECTRONIC  TECHNOLOGY  PROGRESS  AND  LIFE 
CYCLE  SUPPORT 1 

Air.  R.  M.  Lockerd 
Texas  Instruments 

SOFTWARE  VISIBILITY  FOR  THE  PROGRAM 
MANAGER 12 

Lieutenant  Colonel  A.  J.  Driscoll 
United  States  Air  Force 

CONTEMPORARY  MANAGEMENT  - PROFESSIONAL 
ASPECTS 28 

Mr.  D.  D.  Acker 

Defense  Systems  Management  College 
ROLL  OF  CONGRESSIONAL  STAFF  IN  WEAPON 


SYSTEMS  ACQUISITION 34 

Major  J.  W . Allsbrook 
United  States  Air  Force 

WHAT’S  H APPENDED  TO  BASICS? 43 

Mr.  W.  W.  Thybony 
Office  of  Federal  Procurement  Policy 

CALL  FOR  MANUSCRIPTS 54 


M 


IV 


Defense  Systems  Management  Review 


r 

t ■ 

■ 

* 

INTRODUCTION 

For  the  last  two  decades  engineering,  and  the 
world  at  large,  has  been  subjected  to  effects  of  an 
unprecedented  growth  rate  in  new  technology  appli- 
cations. This  rate  of  technological  change  not  only 
has  contributed  to  the  general  development  of  "tran- 
sient” social  patterns,'  but  also,  has  generated  signif- 
icant management  problems  for  some  users  of  so- 
phisticated electronic  equipments.  As  one  of  the 
largest  of  such  users,  the  Department  of  Defense,  in 
conjunction  with  a growing  concern  for  realistic 


budgetary  limitations  and  total  life  cycle  support 
cost,  has  perceived  this  rate  of  technology  change  as 
serious. 


Since  early  1960  when  military  applications  were 
the  primary  driving  force  in  semiconductor  elec- 
tronic evolution,  the  balance  has  shifted  so  that  the 
aggregate  of  all  unique  military  useage  is  less  than  10 
percent  of  the  total  semiconductor  market,  with  a 
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proportionally  reduced  capability  to  direct  the  flow 
of  “mainstream”  technology. 

Problems  associated  with  Life  Cycle  Sup- 
port/Technology interactions  have  been  viewed 
with  varying  degrees  of  alarm  by  management  ana- 
lysts within  the  Department  of  Defense  (DOD), 
with  most  attention  focused  essentially  at  the  level  of 
component  parts — particularly  electronic  devices. 
In  summary,  the  primary  concern  of  DOD  might  be 
stated: 

Doesn’t  the  continued  rapid  pace  of  new 
technology  development  imply  that  systems 
being  developed  today  may  be  logistically  un- 
supportable  - by  reason  of  cost  and/or  parts 
unavailability  - before  their  planned  useful  life 
is  complete? 

The  most  frequently  cited  examples  relate  to  the 
massive  impact  of  the  vacuum  tube-semiconductor 
transition2  that  began  in  the  1950’s  and  still  is 
affecting  DOD  logistics  in  the  mid-1970’s.  Current 
concerns  identify  the  continuing  rapid  evolution  of 
semiconductor  electronics  as  a threat  to  the  level  of 
life  cycle  “supportability.”  From  an  industry  view- 
point the  magnitude  of  this  problem  probably  is 
overstated;  and,  in  fact,  the  situation  has  much  more 
positive  than  negative  potential  on  life  cycle  support 
costs. 

A related,  but  somewhat  separate  potential  prob- 
lem is  now  emerging,  triggered  by  the  major  techno- 
logical impact  of  the  programmable  function  elec- 
tronics (PFE)  now  becoming  available.  The  proba- 
ble long  term  effect  of  the  advent  of  this  technology 
on  life  cycle  cost  and  the  supporting  logistics  system 
has  not  yet  begun  to  be  widely  perceived;  but  it  is 
clear  that  it,  in  fact,  may  have  a substantially  revolu- 
tionary impact  on  those  aspects  of  product  life  cycle 
management. 

A large  number  of  techniques  have  been 
suggested1  for  use  in  managing  interactions  between 
life  cycle  support  and  technological  progress.  From 
an  industry  viewpoint  many  of  these  have  limited 
potential  for  significant  impact,  and  cannot  substi- 
tute for  a well-planned  long  term  cooperative  pro- 
gram jointly  executed  by  the  government  program 
team  and  its  industrial  supplier.  Several  of  these 
techniques  and  some  key  elements  of  such  a co- 
operative program  are  discussed  here. 


LIFE  CYCLE  SUPPORT  VS 
TECHNOLOGICAL  PROGRESS 

DEVICE  TECHNOLOGY  EVOLUTION 
- AN  OPTIMISTIC  VIEW 

There  is  no  denying  that  significant  problems  are 
created  for  long-lived  products  by  the  natural  ten- 
dency of  a free  enterprise  industry  to  “close  out" 
old,  low  volume,  relatively  unprofitable  product 
lines  in  favor  of  newer,  more  cost  effective  items 
with  greater  current  and  future  demand.  Industry 
experience  however,  has  indicated  clearly  that  much 
more  benefit  than  harm  has  resulted  from  the  rapid 
technology  evolution,  even  over  the  last  two  decades 
of  "initial  transients”  in  the  semiconductor  electron- 
ics technology.  The  broad  base  of  system  and  equip- 
ment design  experience  accumulated  over  this  pe- 
riod has  made  possible  the  present  capability  to 
anticipate  and  accommodate  future  evolutionary 
trends.  Finally,  and  possibly  most  important,  natu- 
ral “marketplace”  forces  in  the  entire  con- 
sumer/industrial/governmental market  complex 
are  tending  to  introduce  more  basic  stability  than  is 
apparent  on  surface  inspection.  On  these  bases,  then, 
the  outlook  for  the  future  is  very  favorable.  With  a 
reasonable  amount  of  forethought  and  management 
attention,  the  vast  majority  of  benefits  from  ever- 
improving  technology  can  be  captured  for  most 
existing  and  new  government  electronics  equip- 
ments without  large  off-setting  dangers  to  the  life 
cycle  support  aspects. 

Revolution  or  Evolution? 

A crucial  question  in  consideration  of  life  cycle 
support/technology  interactions  is  whether  we  are 
experiencing  a series  of  “revolutions"  or  a somewhat 
orderly  and  predictable  evolutionary  process.  Much 
time  and  effort  has  been  spent  debating  this  ques- 
tion, and  "technology  forecasting"  is  becoming  a 
whole  new  engineering  discipline.  In  practical  terms 
it  appears  that  the  vacuum  tube-to-transitor  change 
was  revolutionary,  but  that  the  process  since  has 
been  substantially  evolutionary,  albeit  a process  pro- 
ceeding at  a high  rate  and,  at  some  times,  with  a high 
“mutant”  population.  A cursory  reading  of  market 
growth  statistics’  and  projections  and  of  new 
product  surveys,4  in  fact,  will  produce  the  impres- 
sion that  the  process  will  continue  unabated  for  the 
foreseeable  future,  and  this  is  undoubtedly  correct. 
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The  impression  obscures,  however,  some  basic  un- 
derlying evolutionary  trends  which  are  very  favor- 
able to  life  cycle  support  considerations.  These 
trends  may  be  summarized  as  a tendency  for  the 
enormous  “momentum”  of  the  current  solid  state 
electronics  environment  to  produce  natural  resist- 
ance to  noncompatible  new  developments.  This  mo- 
mentum has  grown  in  proportion  with  the  size  of  the 
semiconductor  applications  market  over  the  last  two 
decades,  and  is  a result  of  the  enormous  investments 
already  made  in  fielded  equipment,  specialized  fabri- 
cation and  assembly  capacity,  application  documen- 
tation, other  software,  and  engineering  training  and 
experience.  The  vast  majority  of  this  momentum 
exists  in  non-DOD  electronics  market  segments,  so 
much  so  that  it  effectively  directs  the  mainstream  of 
electronic  developments. 

The  major  observable  effect  of  this  momentum  is 
the  establishment  of  both  formal  and  “de  facto" 
standards  for  semiconductor  devices  at  basic  physi- 
cal and  electronic  interface  levels.  It  is  now,  for 
example,  much  more  difficult  than  only  a few  years 
ago  to  introduce  and  hope  to  sell,  in  significant 
quantities,  a new  semiconductor  component  that 
does  not  have  Transistor-Transistor  Logic  (TTL) 
interface  capability,  and/or  that  does  not  utilize  one 
of  a very  few  commonly  accepted  packages  such  as 
the  dual-inline  integrated  circuit  form  factor.  Even 
where  new  developments  are  needed  for  specialized 
users,  e.g.  high-density  component  packages  for  the 
makers  of  avionics  equipment,  industry-wide 
standardization'  precedes  their  introduction  in  sig- 
nificant volume.  The  net  effect  of  these  trends  has 
been  to  “damp  out”  much  of  the  wide  variation  in 
basic  types  of  devices  and  packaging  seen  during  the 
earlier  days  of  semiconductor  development.  Yet,  it 
has  not,  and  will  not,  put  significant  limitations  in 
the  growth  of  capability,  e.g.  the  growth  from  1 K-bit 
of  memory  per  package  to  1 6K  bit  per  package;  but 
it  does  mean  that  there  is  now  a much  greater  ability 
to 

• anticipate  evolution  in  design  by  appropriate 
modularity,  and 

• execute  logistically  compatible  perform- 
ance/cost improvement  design  changes  as  re- 
quirements and/or  budgets  dictate. 

with  consequent  favorable  effects  on  life  support 
capability. 


The  enormously  favorable  impact  of  technology 
evolution  on  the  cost  and  fuctional  capability  of 
electronic  systems  is  unquestionable,  not  only  in 
military  systems,  but  in  providing  functions  at  very 
nominal  cost  which  literally  were  not  available  at 
any  price  only  a few  years  ago.  Today’s  hand-held 
scientific  calculators,  for  example,  provide  for  a few 
hundred  dollars  as  much  or  more  directly  useable 
computational  ability  than  was  available  for  fixed 
computers  occupying  whole  rooms  and  costing  sev- 
eral orders  of  magnitude  more  in  the  mid-1950’s. 
Despite  highly  favorable  trends  in  the  initial  cost  of 
electronic  capability,  concern  over  low  cycle  cost 
implications  has  focused  on  the  difficulty  of  obtain- 
ing “obsolete”  components  for  required  repair  or 
replacement  of  fielded  systems.  Although  vacuum 
tubes  are  the  most  prominent  single  example,  it  is 
true  that  a significant  number  of  earlier  semiconduc- 
tor device  types  such  as  germanium  transistors, 
Diode-Transistor  Logic,  and  even  “flatpack"  inte- 
grated circuits  are  now  difficult  to  procure.  The 
other  side  of  this  coin  is  that  in  essentially  all  case.-, 
these  items  have  been  replaced  with  items  of  sub- 
stantially improved  performance  and/or  cost;  and, 
in  fact,  their  very  obsolescence  was  usually  caused 
by  the  appearance  of  a substantially  “better  mouse- 
trap.” Industry  experience  has  indicated  that, 
whether  done  voluntarily  or  as  an  inescapable  neces- 
sity, the  process  of  “updating”  systems  to  newer 
component  types  has  consistently  improved  some 
combination  of  function,  reliability,  and  “maintain- 
ability" and,  thereby,  lowered  the  forward  life  cycle 
cost.  In  fact,  it  is  typically  the  case  that  the  usual 
management  of  "mainstream,"  highly  useful  DOD 
systems,  accommodates  any  such  needed  changes  as 
a part  of  the  normal  process  of  product  sustaining, 
value  engineering  changes,  etc.  Typically  it  is  only 
the  marginally  useful  and/or  lower  population  sys- 
tems that  encounter  significant  problems;  and  a very 
real  problem  element  exists  in  the  older  equipment 
which  the  US  government  has  provided  to  other 
countries.  Even  in  these  latter  cases,  the  technical 
problems  are  not  insurmountable.  The  basic  issue  is 
managerial — whether  the  systems'  future  utility  jus- 
tifies an  investment  to  extend  their  life.  No  user  ever 
likes  to  give  up  an  inplace  capability,  but  the  real 
world  principle  of  "growth  or  death”  clearly  applies 
to  electronic  systems  as  to  most  other  functioning 
entities. 
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THE  COMING  IMPACT  OF 


PROGRAMMABLE  FUNCTION 
ELECTRONICS  (PFE) 

It  is  impossible  to  pick  up  a current  electronics 
publication  without  encountering  an  article  on  mi- 
croprocessors, bit  slices,  or  some  other  element  of 
the  family  of  Programmable  Function  Electronics 
(PFE).  As  semiconductor  devices  these  PFE  repre- 
sent only  basic  evolution  in  technology;  but  they  will 
ultimately  precipitate  a revolution  in  the  way  most 
DOD  electronic  equipment  and  systems  are  de- 
signed, produced,  and  logistically  supported. 

Basically,  the  PFE  are  simply  large,  highly  inte- 
grated digital  semiconductor  circuits  that  instead  of 
performing  a completely  “hard  wired”  logic  func- 
tion, have  the  ability  to  perform  a variety  of  opera- 
tions as  directed  by  external  "program"  inputs  or  by 
the  configuration  in  which  they  are  “wired”  into  the 
system.  The  “hardware”  standardization  inherent  in 
the  use  of  PFE  produces  very  low  cost  per  function 
because  of  the  high  production  volume  for  each 
single  device  design.  Depending  on  the  PFE  device 
type,  program  inputs  may  come  from  fixed  prewir- 
ing or  switch  setting,  or  from  the  full  range  of  stored 
program  possibilities  offered  by  ROM*,  PROM*, 
RAM*,  EPROM*,  etc. 

The  desired  function  is  first  generated  as  “soft- 
ware” by  which  the  programmable  device  is  ulti- 
mately to  be  directed,  then  subsequently  committed 
to  “hardware”  by  appropriate  inclusion  in  the  cir- 
cuits controlling  the  PFE.  Because  of  both  the 
economic  and  functional  appeal  of  PFE  for  imple- 
mentation of  most  reasonably  complex  digital  func- 
tions, it  is  probable  that  the  majority,  if  not  almost 
all,  digital  electronic  systems  developed  from  this 
time  on  will  employ  some  forms  of  PFE. 

From  a life  cycle  support  point  of  view,  there  are 
many  significant  aspects  of  the  emergence  of  PFE 
applications  that  will  require  close  attention  of  both 
the  electronic  system  developers  and  the  ultimate 
users.  A few  of  these  aspects  are: 

• The  systems  development  cost  will  swing  to- 
ward much  higher  “software"  content.  As  the 

•(Read  Only  Memory,  Programmable  ROM,  Random  Access 
Memory.  Electronically  Programmable  ROM) 


existing  and  somewhat  artificial  distinctions 
between  “software”  and  “hardware”  blur  fi- 
nally disappear,  both  government  and  industry 
management  must  anticipate  and  accommo- 
date merging  of  the  two  disciplines. 

• Basic  digital  hardware  reliability  will  improve 
as  device  and  interconnection  counts  are  re- 
duced, and  the  raw  production  costs  of  digital 
capability  will  decrease  significantly. 

• Within  fixed  volume,  power,  and/or  weight 
restraints,  significantly  more  digital  "horse- 
power” can  be  provided.  This  capacity  can, 
and  should,  be  devoted  to  self-supporting 
maintenance  functions  such  as  built-in  test, 
remote  “monitorability,”  and/or  redundancy 
for  reliability  as  appropriate. 

• The  basic  flexibility  of  systems  to  accept  post- 
development functional  changes  will  increase 
in  proportion  to  the  software  content.  This  is 
good  news  for  the  direct  user,  but  potentially 
bad  news  for  the  logistician;  and  rigorous  disci- 
pline will  be  required  to  force  realistic 
function/life  cost  tradeoff  to  justify  system 
modifications. 

• To  a large  extent  “throw-away”  replacement 
of  many  digital  functions  will  become  not  only 
possible  but  clearly  advantageous  as  hardware 
costs  decrease  and  more  functions  are  packed 
into  single,  large  integrated  circuit  elements. 

• The  logistical  burden  will  be  simplified  at  the 
piece-part  level  with  one  PFE  replacing  many 
other  integrated  circuits.  Also,  the  high  vol- 
ume useage  of  PFE  elements  will  act  to  ensure 
their  availability  over  a long  time  span. 

• Problems  of  software  maintenance  and  logis- 
tics, which  have  previously  been  confined  to  a 
relatively  few  computer  users,  will  become 
much  more  widespread,  offering  a significant 
challenge  to  logistic  management. 

In  summary,  the  unavoidable  advent  of  PFE  ele- 
ments will  have  a significantly  favorable  impact  on 
life  cycle  support  of  digital  electronics — but  will 
place  a relatively  new  burden  of  software  control  on 
the  logistician  responsible  for  long  term  system 
maintenance. 
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MANAGING  LIFE  CYCLE 
SUPPORT/TECHNOLOGY 
INTERACTIONS 


Management  of  the  development,  deployment, 
and  support  of  electronics  systems — whether  com- 
posed of  relatively  few  similar  “black  boxes”  or  a 
number  of  major  subsystems  of  widely  varying 
types — requires  a never-ending  balancing  of  intri- 
cately involved  factors,  some  of  which  are  due  to  the 
interaction  between  technological  progress  and  life 
cycle  cost  and/or  product  “supportability."  From 
an  industrial  viewpoint,  knowledge  and  consider- 
ation of  the  following  factors  are  key  to  the  proper 
management  of  life  cycle  cost/technology 
interactions: 

• Recognizing  the  real  world  cost  of  technologi- 
cal life 

• Giving  heavy  weight  to  the  use  of  “main- 
stream "technology 

• Recognizing  and  utilizing  the  natural  roles  of 
government  and  industry 

• Facing  up  to  the  procurement  implications  of 
minimum  life  cycle  cost  over  extended  life 

• Realistically  planning  and  controlling  for  de- 
liberate life  cycle  cost  and  lifetime 
characteristics 

The  following  paragraphs  expand  on  each  of  these 
areas,  but  it  will  be  readily  recognized  that  they  all 
unavoidably  interact  and  must  be  considered  to- 
gether as  a normal  part  of  the  systems  management 
function. 


THE  REAL  COST  OF 
TECHNOLOGICAL  LIFE 


The  old  principle  of  “There's  no  such  thing  as  a 
free  lunch”  applies  very  well  to  the  question  of  life 
cycle  cost  for  long-lived  electronic  systems.  In  the 
simplest  terms,  there  is  an  absolutely  unavoidable 
cost  base  involved  in  supporting  any  product  over  a 
long  useful  life  and  someone,  sometime,  will  pay  the 


bill.  This  cost  can  be  minimized  by  proper  manage- 
ment— by  sharing  “pooled”  costs  through  common- 
ality in  “mainstream”  technology  or  standard  parts; 
by  making  the  right  investments  at  the  right  times  in 
tooling,  stockpiling,  etc.;  by  including  life  cycle  cost 
considerations  in  initial  design  guidelines;  etc. — but 
in  no  case  is  the  cost  eliminated,  although  it  can  be 
concealed,  deferred,  or  sometimes  “put  on  the  other 
guy.”  Industry’s  present  sophisticated  management 
methods,  many  of  which  have  evolved  over  the  last 
two  decades,  are  keyed  to  Return-On-Assets  or 
Retum-On-Investment;  and  clearly  illuminate  the 
fact  that  items  with  lowered  production  volumes 
always  develop  very  real  cost  problems.  These  prob- 
lems are  cumulative  with  time  and  are  typically  so 
large  that  continued  production  is  unfeasible  unless 
some  user  needs  the  item(s)  so  badly  that  he  is 
prepared  essentially  to  buy  and  maintain  the  assets 
that  are  required  for  their  production.  This  effect  is 
often  emotionally  characterized  as  an  industry  “rip- 
off’  of  “captive”  users,  which  clouds  visibility  to 
the  real  fact  that  the  cost  is  there  and  someone  must 
bear  it.  As  unpalatable  as  the  fact  may  be  to  the  user, 
either  production  volume  or  direct  costs  must  be 
supplied  to  continue  supporting  basic  manufactur- 
ing capability,  and  the  more  sophisticated  the 
product,  the  more  this  rule  applies. 

The  implications  of  these  facts  to  the  government 
systems  manager  is  that  he  is  offered  an  opportunity 
relatively  early  in  the  life  cycle  of  his  product  to 
recognize  and  plan  for  these  costs,  or  ignore  them 
and  be  surprised  later.  Recognition  of  these  basic- 
factors  usually  requires  life  cycle  planning  for  both 
periodic  design-updating  investments  to  minimize 
forward  life  cycle  cost  and  for  realistic  and  substan- 
tial cost  escalation  for  additional  systems  and/or 
spares  after  the  main  production  phase  of  the  pro- 
gram is  past.  As  the  character  in  a current  television 
commercial  says.  “You  can  pay  me  now  or  pay  me 
later.” 

THE  VALUE  OF  MAINSTREAM 
TECHNOLOGY 

It  is  first  useful  to  consider  what  constitutes  the 
"mainstream"  of  solid-state  electronics  technology. 
While  the  flow  of  this  mainstream  carries  with  it  a 
multitude  of  specific  devices,  the  most  fundamental 
aspect  is  not  the  particular  device  types  but  the 
processes  by  which  they  are  made,  and  the  resulting 
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physical  and  electronic  interfaces  with  the  “outside” 
world.  The  basic  value  of  mainstream  participation 
is  due,  essentially,  to  one  factor — it  is  possible  to 
share  the  cost  of  development,  production,  and  the 
maintenance  of  availability  over  life  with  many 
other  users  rather  than  bearing  the  cost  alone. 

Because  unique  or,  at  least,  distinctive  require- 
ments exist  in  many  military  electronic  systems,  the 
temptation  almost  always  exists  to  develop  special- 
ized devices  for  the  implementation  of  these  require- 
ments. There  is  also  a large  segment  of  industry  with 
specialized  circuit  capability  whose  basic  existence 
depends  on  “selling”  the  need  for  such  develop- 
ments and  their  subsequent  production;  and  they 
provide  an  important  and  needed  function.  Con- 
versely, probably  one  of  the  most  valuable  traits  that 
could  exist  in  a modern  electronics  program  man- 
ager is  a healthy  skepticism  about  the  need  of  and/or 
wisdom  of  such  developments.  In  fact,  a “zero-base- 
budgeting” approach  starting  with  "Why  can't  we 
use  commercial  devices"  would  be  useful  in  many 
cases.  Some  basic  ground  rules  are: 

• When  possible,  use  commercial  devices  either 
directly  or  with  screening  at  the  “bar” 
production  level*  for  subsequent  military  qual- 
ified packaging. 

• When  using  PFE  devices,  be  prepared  to 
"overkill"  the  hardware  capacity  in  places  to 
utilize  common,  standard  device  types  that  are 
running  well  below  their  maximum  capability. 

• If  a unique  circuit  is  required,  don’t  develop 
one  involving  basic  processes  not  solidly  in  the 
mainstream.  The  cost  of  developing  and  main- 
taining a unique  semiconductor  process  capa- 
bility is  enormous  and  almost  impossible  to 
amortize  over  any  realistic  volume  for  defense 
equipment  alone. 

• A corollary  of  the  above  is  that  the  use  of 
special  “hybrid"  devices  should  be  carefully 
evaluated.  Almost  without  exception,  if  size, 
etc.  permits,  separate  digital  and  analog  cir- 
cuits will  minimize  ultimate  life  cycle  cost. 


• Manufacturing  point  where  the  device  has  not  yet  been 
packaged. 


• Avoid  the  lure  of  greatly  understating  the 
future  cost  of  special  devices.  The  cost/volume 
laws  that  control  semiconductor  costs  are  as 
inexorable  as  entropy.  Beware  of  suggestions 
that  the  device  will  “catch  on  in  the  commer- 
cial market."  A good  test  is  that  if  a major 
semiconductor  manufacturer  can’t  easily  be 
interested  in  developing  the  device — beware. 
The  cost  of  a “special”  can  also  skyrocket  if  the 
original  vendor  should  disappear  or  lose 
interest. 

To  illustrate  these  effects,  a gross  comparison  of 
some  present  and  future  semiconductor  products  of 
the  various  types  mentioned  is  of  interest.  Some 
typical  data  are  shown  in  Table  1.  While  the  abso- 
lute values  presented  will  vary  with  time  and  other 
circumstances,  the  ratios  can  be  expected  to  remain 
essentially  fixed  and  the  cost  of  uniqueness,  even  for 
relatively  high  volume  special  circuits,  may  be 
clearly  seen.  The  logic  power/cost  impact  of  the 
PFE,  in  this  case  a microprocessor,  may  also  be  seen, 
both  at  the  present  and  projected  to  the  near  future 
when  the  use  of  PFE  will  become  more  pervasive. 

GOVERNMENT  AND 
INDUSTRY  ROLES 

The  natural  responsibilities  of  the  government 
system  manager  iri  system  requirements  definition, 
interface  with  the  ultimate  users,  operational  test- 
ing, and  initial  deployment  are  clear  and  distinct 
from  industry’s  role  in  fabrication  and  initial  system 
testing.  This  distinction  of  natural  and  most  effective 
roles  is  not,  however,  nearly  so  clear  in  two  key  areas 
- system  design  and  post-production  support.  It  is 
these  two  areas,  both  of  which  heavily  impact  ECC, 
that  most  challenge  the  coordinated  management 
skills  of  the  participants.  Whole  volumes  have  been 
written  on  this  subject,  and  it  obviously  is  not 
appropriate  to  address  these  issues  fully  here  Some 
observations  on  LCC/technology  implications  are. 
however,  offered  for  the  consideration  of  potential 
program  managers; 

• In  the  design  phase,  both  parties  must  be 
willing  and  qualified  to  participate  jointly  on  a 
very  candid  basis  in  life  cycle  cost  projections. 
If  the  task  is  done  alone  by  either  government 
or  industry,  or  under  contraints  of  "finding  the 
known  answer,"  the  effort  will  probably  not  be 
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Relative  Digital  Electronic  Costs 


TTL*  Device  Type 

Package 

Cost  (Dollar/logic  "Gate'') 

Custom,  hi-environment, 
"hardened” 

Special 

2.00  - 5.00 

JAN  TX  TLL  Logic 

Ceramic  DIP** 

0.25  - 0.30 

Screened  SNC-SNJ*** 

Ceramic  DIP** 

0.12  - 0.18 

Commercial 

Plastic  DIP** 

0.05 

Microprocessor  with 
military  environment 
capability 

Ceramic  DIP** 

0. 1 5 present 

( 

0.01  - 0.005  in  mature 

production 


*T  ransistor-T  ransistor-Logic 
**Duai  Inline  Package 

***SNC  Reliability  Screened  for  MIL  STD  883B;  SNJ  Dual  Inline 
Ceramic  Package  Integrated  Circuit 


worth  its  cost.  In  unique  cases,  one  or  the  other 
party  might  be  qualified  to  do  life  cycle  cost 
alone,  but  such  cases  would  be  few.  Remember 
that  understanding  LCC  theory  or  having  a 
nice  computer  model  is  not  the  same  as  really 
projecting  life  cycle  cost.  The  old  computer 
adage  of  “garbage-in/garbage-out"  applies. 

• In  the  design  phase  more  than  lip  service  must 

be  paid  to  life  cycle  cost.  Investing  dollars  now 

to  save  later,  or  settling  for  less  capability  now 
with  more  to  be  added  (easily)  later  are  issues 
that  must  usually  be  raised  by  the  designer  and 
quickly  and  decisively  evaluated  by  the  govern- 
ment managers.  The  cost  of  a delayed  or  de- 
ferred decision  can  easily  cancel  out  or  exceed 
the  potential  savings  if  a “tight  loop”  is  not 
maintained. 


• The  industrial  supplier  will  have  a “handle"  on 
lower  tier  suppliers,  know  the  system  or  equip- 
ment, have  management  continuity  in  the  tech- 
nical areas  involved,  and  have  facilities  for 


repair,  renovation,  etc.  The  government  man- 
ager must  be  prepared  to  evaluate  the  possibil- 
ity of  commitments  to  extended  contractor 
support  early  in  the  program,  so  that  proper 
decisions  can  be  made  on  tooling,  facilities,  and 
stockpiling.  If  this  support  is  integrated  with 
planned  design  updates  by  the  supplier,  the 
overall  cost  will  be  lowered,  and  significant 
LCC  reductions  and  useful  life  extensions  will 
result. 


PROCUREMENT  IMPLICATIONS 

The  value  of  competition  in  our  free  enterprise 
system  is  unquestionable,  and  the  basic  concept  is  so 
deeply  ingrained  in  our  thinking  that  it  is  difficult  to 
ask  objectively,  "At  what  point  may  competition 
become  disadvantageous  to  the  buyer  of  a product?" 
This  is,  however,  a question  to  be  carefully  consid- 
ered in  the  life-cycle  management  of  modern  DOD 
systems.  In  particular,  life  cycle  support  and 
cost/technology  interactions  have  significant  impli- 
cations in  terms  of  how  the  procurement  of  systems 
and  equipment  may  best  be  structured  to  accommo- 
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date  competition.  For  example,  in  an  environment 
of  dual-source,  design-to-life  cycle  cost  competitive 
developments,  the  traditional  government  attitude 
toward  long-term,  sole-source  commitments  should 
be  restudied.  With  the  plethora  of  cost  accounting 
standards,  program  cost  reporting,  inprocess  and 
postcontract  audits,  and  resident  government  in- 
spectors; the  old  specter  of  excessive  profits  by  a 
sole-source  vendor  can  be  laid  to  rest.  The  necessity 
for,  and  effectiveness  of,  compulsory  re-competition 
for  additional  production,  spares,  etc.  is  probably 
much  more  psychological  and  political  than  practi- 
cal in  terms  of  reducing  overall  life  cycle  cost  and 
developing  the  potential  for  extended  system  life. 
The  possible  benefits  of  selecting  a single  supplier  for 
long-term  product  commitments  are  many: 

• A vendor  with  visibility  to  long  term  return  on 
in  tment  is  able  to  take  much  larger  “front- 
ena  risk,”  that  can  result  in  lower  government 
LCC.  In  development  phases,  these  invest- 
ments may  appear  as  support ive  IR&D  and/or 
cost  sharing  of  developments;  in  later  phases, 
as  self-funded  development  of  “value  engineer- 
ing" proposals  to  incorporate  technological 
developments  for  improved  function,  lower  life 
cycle  cost,  etc. 

• Vendors  with  long  term  visibility  can  afford 
significantly  greater  investments  in  facilities, 
tooling,  and  other  resources  that  may  improve 
product  quality,  reliability,  and/or  a vendor’s 
ability  to  respond  rapidly  to  changing 
production  or  technology  requirements. 

• With  longer  visibility,  the  primary  vendor  has 
much  more  leverage  to  negotiate  favorable 
price,  specification,  and  delivery  agreements 
with  lower  tier  suppliers;  and  their  product 
may  also  show  some  of  the  beneficial  effects  of 
manufacture  in  a more  stable  demand  environ- 
ment. Longer  continuity  of  product  availabil- 
ity may  also  result. 

• All  of  the  contractor  support  advantages  that 
have  been  noted  may  be  obtained  and  the 
government  logistic  system  is  not  burdened 
with  handling  nearly  as  many  individual  part 
types. 


In  summary,  long-term  commitments  to  “single 
source”  suppliers  for  government  electronics  sys- 
tems can,  and  should,  be  favorably  considered  as 
means  to  improve  life  cycle  support/technology 
interactions. 

In  discussing  the  topic  of  sole  source  commit- 
ments for  product  life  support,  the  question  is 
asked, "Doesn’t  it  mean  that  smaller  outfits  will  get 
driven  out  of  business  by  the  big  primes”?  The 
answer  to  this  is  definitely  “NO,"  and,  in  fact,  it  is 
probable  that  most  smaller,  lower  tier  suppliers  had 
much  rather  do  business  under  these  circumstances. 
Smaller  companies  with  good  quality  products  bene- 
fit from  a predictable  market  even  more  than  larger 
ones;  and,  when  part  of  a stable  team,  actually  feel 
the  benefit  of  a “buffer"  with  more  staff  capability  to 
predict  business  trends,  manage  the  government 
interface,  and  quickly  fix  problems.  On  this  basis, 
the  lower  tier  suppliers  benefit  more  than  the 
"prime"  from  long  term  commitments  to  product 
support  by  the  government. 


SOME  MANAGEMENT  TECHNIQUES 

Many  techniques  for  controlling  life  cycle 
support/technology  interactions  have  been  sug- 
gested, studied,  and  discussed  by  both  government 
and  non  government  system  managers.  A recent 
paper  in  this  publication  presented  a survey  of  some 
of  the  more  important  of  these  techniques,  and 
summarized  one  government  manager's  view  on 
their  use.'  Brief  comparative  comments  from  an 
industry  viewpoint  are  presented  below  on  a few  of 
the  techniques: 

• Modular  design 

• Standard  parts 

• Stockpiling 

• Reliability  improvement  warranties 

• Scheduled,  life  cycle  support -oriented  product 
design  updates 
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Modularity 

Modularity  of  design  has  a number  of  well-known 
attributes,  most  of  which  bear  directly  on  life  cycle 
cost,  for  example,  economy  of  volume  in  production 
and  field  “maintainability”;  but  its  effects  on  life 
cycle  cost/technology  interaction  are  equally  impor- 
tant. In  this  connection  it  is  important  to  recognize 
that  modularity  must  be  looked  at  on  multiple 
levels — not  necessarily  confined  to  the  “Line- 
replaceable  module”  popular  in  logistics.  For  exam- 
ple, in  the  implementation  of  solid-state  memories  it 
is  possible  to  anticipate  progressively  higher  densi- 
ties in  interchangeable  packages  e.g.  1-K  bit 
RAMS*  are  beginning  to  be  supplanted  by  16-K  bit 
packages,  which,  in  turn,  will  almost  certainly  be 
joined  by  higher  density  devices.  If  effects  such  as 
these  are  considered  (“designing  for  technology”)  in 
initial  system  architecture  and  partitioning  phases, 
the  cost  of  later  inclusion  of  such  elements  can  be 
minimized  and  the  logistics  pipeline  smoothly 
“turned  over”  to  newer  technology  products 

Standard  Parts 

The  use  of  standard  parts  is  closely  allied  to  that  of 
modularity  and,  like  motherhood,  is  unquestionably 
necessary  and,  usually,  desirable.  The  real  question 
devolves  to  one  of  how  “current”  it  is  possible  to 
maintain  standard  parts  lists  for  high  technology- 
products.  Experience  has  shown  that  government- 
controlled  standard  parts  lists  lag  the  best  current 
component  availability  by  at  least  1 year,  and  more 
typically  2 or  3;  with  critical  items  like  semiconduc- 
tors and  connectors  presenting  the  worst  problem. 
Some  lag  is  inevitable,  but  the  implication  again  is 
that  the  government  manager  must  be  prepared  to 
deal  rapidly,  competently,  and  with  an  open  mind 
with  his  industrial  counterpart  on  questions  of  non- 
standard parts.  Large  development  programs,  like  a 
waiting  taxi,  always  have  the  "meter  running,"  and 
delays  for  relatively  minor  parts  deviations  can  cost 
literally  thousand  of  times  the  parts’  worth  in  devel- 
opment costs. 

The  development  of  families  of  standard  function 
modules,  such  as  the  US  Navy’s  SEM  (Standard 
Electronic  Modules)  is  an  approach  with  much 
appeal  for  the  government  logistician;  and  is  also,  in 
general,  favorably  viewed  by  most  industry  manag- 
ers, but  with  some  strong  reservations,  e.g.: 

• (Random Recess  Memories ) 

Vol  I,  No  2. 


• The  cautions  noted  about  the  inherent  cost  of 
substantial  deviation  from  the  mainstream  will 
have  to  be  carefully  observed,  or  the  expected 
favorable  cost  impact  could  rapidly  reverse  to 
become  a major  cost  burden. 

• More  highly  specialized  and  integrated  func- 
tions— particularly  of  “hybrid”  circuits — are 
more  vulnerable  to  technological  obsolescence; 
and  the  inertial  effect  of  standard  “stockpiles” 
may  dictate  continued  use  of  out-of-date  tech- 
nology, thus  severely  impacting  design  capabil- 
ity by  unacceptably  prebiasing  normal 
cost/function  tradeoffs. 


Stockpiling 

“Stockpiling"  as  a hedge  against  technological 
"rollover"  on  parts  availability  is  probably  one  of 
the  highest  risk,  least  productive  techniques.  Elec- 
tronic component  stockpiling,  in  particular,  is  risky 
unless  done  very  carefully,  because  the  stockpiling 
effort  usually  completely  “closes  out”  production 
capability  for  the  devices  in  question.  Further, 
“sampled”  quality  test  procedures  which  are  quite 
acceptable  for  “production”  items  are  inadequate 
for  stockpiling.  These  components  are  intended  to 
be  "all  there  is"  with  no  realistic  subsequent  re- 
course to  vendors  for  repair  or  replacement.  This 
means  that  100  percent  inspection  and  testing  in- 
cluding, if  possible,  stress  testing  should  be  done  as 
any  item  is  stockpiled.  Resources  for  storage,  and 
retrieval,  also  must  be  furnished  for  the  intended  life 
of  the  product. 

Reliability  Improvement  Warranty 

While  the  case  for  utilizing  the  relatively  new 
concept  of  Reliability  Improvement  Warranty  as  a 
tool  for  managing  early  product  life  cycle  support  is 
reasonable,  it  is  at  best,  a questionable  one  for 
dealing  with  long  term  life  cycle  support/technology 
interactions.  During  the  relative  short  term  of  the 
Reliability  Improvement  Warranty  the  contractor  is 
“on  the  hook”  to  keep  sources  of  supply  active  for 
the  product,  but  this  is  typically  not  the  part  of  a 
product  life  cycle  where  technological  “rollover" 
problems  exist.  Unless  the  durations  of  the  Reliabil- 
ity Improvement  Warranty  are  drastically  extended, 
it  appears  unlikely  that  they  will  make  any  signifi- 
cant impact  on  life  cycle  support /technology- 
interactions. 
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Planned  Design  Updates 

Probably  the  most  powerful  technique  for  manag- 
ing life  cycle  support/technology  impact  is  the  use  of 
planned,  periodic  “design  updating”  by  either  the 
original  designer  or  an  equally  competent  source. 
These  exercises  should  be  scheduled  and  budgeted  as 
a normal  part  of  the  product  life  cycle.  In  most 
cases,  the  “raw”  cost  of  these  updates  will  be  a small 
fraction  of  the  total  product  life  cycle  cost;  and 
industry  experience  indicates  that  the  forward  life 
cycle  cost  savings  will  normally  more  than  repay 
these  costs.  In  the  past,  the  reduction  in  forward  life 
cycle  cost  has  been  associated  with  “step  function" 
improvements  in  reliability  and/or  “maintainabil- 
ity” made  possible  by  the  the  availability  of  new 
technology  and  more  product  experience.  It  should 
be  emphasized  that  these  efforts  are  not  to  be 
“changes  for  the  sake  of  change,”  but  must  incorpo- 
rate fundamental  analytical  techniques  to  demon- 
strate clearly  the  forward  life  cycle  support  advan- 
tage of  any  proposed  change.  The  analyses  must 
include,  at  a minimum,  weighing  of  life  cycle  cost 
impacts  from  changes  in  reliability  and  maintenance 
requirements,  as  well  as  the  value  of  introducing 
improved  functional  capabilities. 


SUMMARY 


In  considering  interactions  between  Life  Cycle 
Support  and  Electronic  Evolution  from  an  industrial 
viewpoint,  the  following  summary  observations  may 
be  made: 


The  overall  detrimental  impact  of  rapid  tech- 
nology development  probably  has  been  sub- 
stantially overstated.  With  proper  attention  to 
management  and  technical  considerations, 
technological  improvements  can  be  incorpo- 
rated routinely  after  the  development  phase, 
both  to  enhance  functional  capability  and  to 
reduce  forward  life  cycle  costs. 


“programmable"  function  electronics.  Prepa- 
ration should  begin  to  accommodate  routinely 
the  associated  “software”  logistics,  that  will 
impose  a major  new  stress  on  the  overall  logis- 
tic system. 

• The  key  to  managing  life  cycle  cost/tech- 
nology interactions  is  a fundamental  under- 
standing of  the  cost  and  availability  factors  for 
"mainstream”  versus  "unique"  electronic 
components.  Those  performing  realistic  life 
cycle  planning  must  recognize  that  there  is  a 
real  price  to  be  paid  for  product  lifetime,  and 
early  provision  made  for  both  minimizing  and 
paying  this  price. 

• Particularly  in  the  case  of  long-lived,  complex 
electronic  systems  for  which  competitive, 
design-to-cost  developments  have  been  done, 
the  leverage  of  long-term  commitments  to  a 
single  contractor  should  be  utilized.  Modifica- 
tion of  existing  procurement  policies  may  be 
required  to  implement. 

• Probably  the  most  powerful  management  tool 
for  optimizing  life  cycle  support/technology 
interactions  is  the  introduction  of  planned  de- 
sign updates  during  the  normal  product  life 
cycle.  Such  updates  will  typically  repay  their 
cost  many-fold  by  reducing  forward  life  cycle 
cost  through  reliability  and  other  improve- 
ments; and,  frequently  will  increase  functional 
capability  and  extend  the  product’s  useful 
lifetime. 


Mr  Robert  M Lockerd  is  a De- 
partment and  Business  Strategy 
Manager  for  Air  Traffic  Control 
Products,  Equipment  Group. 

Texas  Instruments.  Incorpo- 
rated Mr  l.ockerd*s  prior 
experience  includes  program 
management  and  systems  engineering  of  data  communications 
and  spacecraft  data  communications  and  spacecraft  data  systems. 
Since  1%9  Mr  Lockerd  has  served  as  a member  of  the  L’S  Arms 
Scientific  Advisory  Panel 
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• There  will  be  a significant  impact  on  basic 
electronic  systems  design  and  life  cycle  logis- 
tics from  the  advent  of  more  highly  integrated. 
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SOFTWARE  VISIBILITY 
AND 

THE  PROGRAM  MANAGER 

by 

Alan  J.  Driscoll,  LtCol,  USAF 


Software  and  the  Program  Manager — What  is  software  in  the  terms  of  a Program 
Manager?  How  can  he  manage  software  development  in  his  program?  The  virtual 
explosion  in  the  use  of  computer  resources  in  modern  weapon  systems  empha- 
sizes the  need  for  an  understanding  of  computer  software.  Attempts  to  use 
inadequate  software,  lax  software  control,  and  the  problems  associated  with 
software  misuse,  have  been  addressed  repeatedly  in  current  literature  and 
speeches. 

Software  visibility  is  explained  here  by  an  Air  Force  author  who  tells  how  software 
problems  affect  costs,  schedules,  and  performance;  how  to  combat  these  prob- 
lems; and,  why  software  is  of  urgent  importance  to  Program  Managers. 


*;  i 
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PART  I 

INTRODUCTION 


THE  SITUATION 

Software  has  meaning  .oa  Program  Manager  only 
in  terms  of  how  it  relates  to  his  total  program. 
Software,  like  hardware,  is  important  in  terms  of 
cost,  schedule,  and  performance,  therefore  it  must 
be  given  the  same  type  of  management  attention  that 
is  given  hardware.  Lack  of  this  type  of  management 
attention  has  been  all  too  evident.  The  result  has 
been  that  problems  in  the  early  developmental  phas- 
es— problems  such  as  inadequate  requirements  defi- 
nition and  improper  integration  of  hardware  and 
software  requirements  have  been  aggravated — then 
magnified  in  later  phases — by  other  problems  such 


as  inadequate  staffing  and  the  inability  to  measure 
software  development  progress. 

Affirmative  action  such  as  putting  software  at  a 
high  level  in  the  Work  Breakdown  Structure  and 
including  software  in  the  Systems  Requirements 
Analysis  (SRA)  can  alleviate  many  pervasive  prob- 
lems. None  of  the  many  actions  required  to  avoid 
the  problems  can  be  accomplished  without  early, 
long-term  planning. 

To  those  professionally  concerned  with  systems 
acquisition  it  is  not  surprising  that  there  is  a rising 
level  of  interest  in  software  on  the  part  of  the 
government.  This  is  especially  true  of  the  Depart- 
ment of  Defense  (DOD).  The  interest  is  due  in  part 
to  the  extremely  high  cost  of  software — regarded  by 
many  persons  as  being  “merely"  data.  The  key  for 
any  Program  Manager  in  obtaining  suitable  soft- 
ware is  to  elevate  software — remove  it  from  the 
category  of  "data"  and  plan  for  its  development  on 
a level  of  importance  with  hardware. 
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SOFTWARE  IMPORTANCE 


For  most  weapon  system  development  programs 
that  incorporate  both  hardware  and  software,  the 
computer  software  is  a critical  component  relative  to 
the  overall  operation  of  the  system.  (Mangold,1  p 
13).  There  are  two  reasons  why  the  Program  Man- 
ager should  be  concerned  with  the  software  of  his 
system.  First,  software  performance  is  critical  to  the 
success  of  his  program.  Second,  his  software  will 
receive  high-level  attention.  The  need  for  an  error- 
free  computer  program  is  obvious  in  the  case  of  the 
guidance  and  control  flight  software  for  a missile 
such  as  the  Minuteman  Intercontinental  Ballistic 
Missile  (ICBM).  Here  a minor  software  error  can 
cause  inflight  failure  of  a vehicle  costing  millions  of 
dollars.  An  undetected  flaw  can  seriously  degrade 
the  operational  missile  force.  Although  an  error  may 
not  cause  such  spectacular  results  in  many  systems, 
schedule  slips,  rework,  and  degraded  performance 
can  escalate  cost  in  a comparable  manner. 


The  Need  to  Know 


What  does  the  Program  Manager  need  to  know 
and  be  concerned  about  regarding  the  software  in  his 
weapon  system?  Essentially,  he  needs  to  know  the 
same  basic  things  that  he  is  required  to  know  about 
his  hardware.  The  basics  are: 

• Does  the  software  meet  performance 
requirements? 

• Is  the  software  within  cost? 

• Is  the  software  on  schedule? 


In  the  “DOD  Weapon  Systems  Software  Manage- 
ment” study  report  prepared  by  Johns  Hopkins 
University,  it  is  stated  that  a lack  of  software  visibil- 
ity, when  compared  with  that  of  hardware,  contrib- 
uted to  the  fact  that  software  was  not  well  managed? 
The  report  also  said  that  visibility  could  be  increased 
by  putting  software  on  a par  with  hardware  (Johns 
Hopkins?  p 2-4)  and  addressed  ways  of  accomplish- 
ing this  equality. 


material  presented  may  be  applicable  to  general 
automatic  data  processing  (ADP)  systems.  The  re- 
search conducted  was  directed  to  systems  that  are 
under  the  purview  of  the  Air  Force  800  series 
regulations.  Study  was  centered  on  the  management 
of  software  from  the  viewpoint  of  a Program  Man- 
ager who  has  responsibility  for  both  hardware  and 
software — the  total  system.  * 

Research  and  Governing  Documents 

Research  for  this  article  was  conducted  in  three 
separate  but  related  investigations.  1)  The  results  of 
a search  of  current  literature  on  problems  that 
Program  Managers  encounter  in  software  develop- 
ment, and  potential  solutions  to  those  problems,  are 
presented  in  Part  II.  2)  A review  of  applicable  DOD 
Policy,  Directives,  and  Regulations,  is  presented  in 
Part  III.  In  Part  IV  a summary  and  observations  are 
presented. 

SOFTWARE  COSTS 

Since  the  advent  of  the  digital  computer,  the  ratio 
of  software  costs  to  hardware  (the  computer  and 
related  peripheral  equipment)  costs  have  undergone 
enormous  increase.  This  phenomenon  is  represented 
in  Figure  1. 
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Figure  1.  Hardware/Software  Trends 
From  "Defense  Management  Journal,  ” 

Vol  11(4):  24  (1975). 

Similar  charts  have  appeared  in  many  publica- 
tions and  are  commonly  accepted  as  the  conceptual- 
ization of  increasing  software  costs.  To  Program 
Managers  this  situation  raises  the  question:  How  can 
I get  control  of  system  software?  How  can  I place 
emphasis  upon  software  from  where  I stand? 


System  Responsibility 

This  article  is  limited  to  software  associated  with 
embedded  computer  systems  although  some  of  the 


* In  this  article  software  development  activity  is  discussed 
only  to  the  point  when  a completed  computer  program  is 
ready  for  operational  use.  The  operational,  maintenance, 
and  modification  aspects  of  software  are  not  discussed  in 
any  detail. 
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Relevance 

The  relevance  of  increasing  software  costs  to  Pro- 
gram Manager  actions  becomes  clear  when  consid- 
eration is  given  the  high  number  of  weapon  systems 
that  contain  computer  systems.  In  an  Aviation 
Week  Conference  Report,  Jacques  Gansler,  Deputy 
Assistant  Secretary  of  Defense  for  Materiel  Acquisi- 
tion, said  that  a Pentagon  study  “identified  115 
different  defense  systems  that  employ  “embedded 
computers”  of  which  approximately  one-half  are 
now  in  service  and  the  other  half  are  under  develop- 
ment.” (Aviation  Week,'  p 43).  Gansler  is  also 
quoted  as  saying  “According  to  our  estimate,  the 
Pentagon  is  spending  more  than  $3  billion  annually 
for  software  for  defense  systems.”  (Aviation  Week,' 
p 41).  He  went  on  to  state  that  68  percent  of  the 
amount  is  spent  during  system  development  and  32 
percent  is  spent  for  operating  and  maintenance 
costs.  Another  estimator  of  software  costs  states  that 
“Current  annual  expenditures  for  embedded  com- 
puter systems  exceed  $2  billion,  with  more  than  70 
percent  of  this  amount  dedicated  to  software.”* 

This  amount  of  money  is  obviously  not  a trivial 
sum,  yet  cost  is  only  one  facet  of  the  software 
picture.  The  other  side  of  the  story  is  unsatisfactory 
software  performance,  or,  more  simply,  its  unrelia- 
bility. Barry  C.  DeRoze,  Directorate  for  Weapons 
Support  Systems  Acquisition,  Office  of  the  Assistant 
Secretary  of  Defense  (Installations  and  Logistics), 
has  said: 

“Although  hardware  reliability  has  improved  sub- 
stantially, the  corresponding  gains  in  system  relia- 
bility have  not  been  realized.  This  apparent  con- 
tradiction arises  because  software  unreliability — 
the  failure  of  software  to  satisfy  the  stated  opera- 
tional requirements — has  become  the  “tall  pole  in 
the  tent”  in  determining  the  reliability  and  opera- 
tional readiness  of  systems.”  (DeRoze,*  p 3). 


Further  indication  of  the  high-level  interest  in  soft- 
ware is  expressed  in  the  statements  made  by  the 
Director  of  Defense  Research  and  Engineering  to 
the  94th  Congress,  Second  Session,  1976: 

“The  urgent  need  for  reducing  the  costs  of  com- 
puter software  was  described  in  last  year’s  Posture 
Statement.  A DOD  Directive  resulting  from  a 


comprehensive  study  is  currently  being  coordi- 
nated that  will  require  the  use  of  improved  proce- 
dures in  software  acquisition.  A DOD  Software 
Management  Steering  Committee  has  been  for- 
mally established  to:  (1)  review  DOD  software 
technology  programs,  (2)  recommend  needed 
areas  of  research  and  emphasis,  and  (3)  plan  a 
balanced  and  coordinated  software  program."' 

Management  Visibility 

Numerous  studies  have  been  made  to  ascertain 
how  to  improve  the  management  of  software.  One  of 
the  foremost  themes  noted  is  the  need  for  “manage- 
ment visibility”  of  software.  For  example,  one  of  the 
four  subelements  of  the  main  objective  of  the  DOD 
Weapon  Systems  Software  Management  Program  is 
“to  promote  management  visibility.”' 

This  then  leads  us  back  to  the  purpose  of  this 
article:  To  determine  and  report  just  what  “software 
visibility”  means  to  the  Program  Manager. 


PART  II 

Software  Management  Ideas 

THE  PROCESS 

To  talk  about  software  cost,  schedule,  and  perfor- 
mance without  covering  the  various  steps  in  the 
software  development  process  is  almost  impossible. 
It  is  difficult  to  separate  cost,  schedule,  and  perfor- 
mance, and  it  is  very  difficult  to  determine  what  the 
Program  Manager  should  do  to  obtain  visibility  for 
each  of  these  separate,  yet  closely  related,  factors. 
Here,  the  software  development  process  is  discussed 
along  with  the  relation  of  cost,  schedule,  and  perfor- 
mance visibility  to  each  phase  in  the  development 
process. 

Definitions 

The  software  development  process  has  been  de- 
fined by  many  people  in  many  different  ways.  These 
steps  range  from  the  seven  steps  expressed  by  Eldon 
R.  Mangold  (Mangold,'  p 2-8)  to  the  three  steps  of 
Boyd  Etheredge(Etheredge,  p 21). 
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Steps  in  the  Process 

The  steps  in  the  software  development  process  as 
defined  by  Mangold: 

1 . System  requirements 

2.  Software  requirements 

3.  Preliminary  design 

4.  Detailed  design 

5.  Code  and  debug 

6.  Test  and  preoperations 

7.  Operation  and  maintenance 

The  steps  in  software  development  process  as  de- 
fined by  Etheredge: 

1 . Analysis  and  design 

2.  Implementation  and  test 

3.  Delivery  and  maintenance 

In  writings  about  the  cost  of  developing  large- 
scale  software  programs,  R.  W.  Wolverton  discusses 
what  he  calls  the  40-20-40  rule.  (Wolverton,"  p 13). 
The  rule  was  developed  empirically  and  says  that  the 
total  resources  (cost)  for  software  development  will 
be  split  40  percent  for  analysis  and  design,  20  per- 
cent for  coding  and  debugging,  and  40  percent  for 
checkout  and  test.  I have  used  a slight  variation  of 
these  three  phases  that  I label: 

• Analysis  and  Design.  This  step  includes  the 
first  four  steps  of  Mangold’s  process. 

• Implementation.  This  is  the  code  and  debug 
step  of  Mangold  and  Wolverton. 

• Verification.  A step  essentially  the  same  as  the 
checkout  and  test  step  of  Wolverton. 

Various  tools  and  ideas  suggested  by  writers  in 
government  and  industry  as  linking  cost,  schedule, 
and  performance  visibility  throughout  software  de- 
velopment are  examined  here. 


ANALYSIS  AND  DESIGN 

Analysis  and  design  begins  with  a definition  of 
system  requirements  and  progresses  through  the 
development  process  to  software  allocation  to 
achieve  complete  design.  The  latter  is  a critical  step 
that  will  affect  the  total  development  cycle.  The 
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criticality  of  establishing  system  requirements  and 
software  requirements  is  stressed  by  Winston  W. 
Royce. 

“...In  our  judgment  the  single  most  important 
cause  of  poor  management  of  software  projects  is 
the  inability  to  successfully  accomplish  these  first 
two  phases  of  requirements  analysis.”  (Royce," 
P 1-13) 

Royce  goes  on  to  say  that  without  requirements 
analysis  the  first  step  in  software  development  is 
design.  This,  of  course,  is  a prelude  to  disaster.  In 
actuality  there  are  probably  no  projects  where  de- 
sign is  done  without  someone  thinking  they  have 
defined  the  requirements.  The  real  question  then  is: 
How  do  you  know  or  ensure  that  the  requirements 
have  been  defined  in  a proper  manner?  One  step  is  to 
get  the  user  involved.  The  ultimate  requirements  are 
his.  Again  quoting  (Royce,"  p 1-21): 

"...The  user  of  the  software  must  be  capable  of 
injecting  his  expertise  into  the  software 
product...” 

and 

“...A  complete,  detailed,  accurate  set  of  perfor- 
mance and  implementation  requirements  which 
has  been  fully  coordinated  with  the  user  is  the  first 
step  in  ensuring  compliance  with  operational  re- 
quirements." ’ 


The  Program  Manager  must  ensure  that  his  soft- 
ware people  are  involved  in  the  total  system  engi- 
neering process,  and  interface  directly  with  the  user. 
Software  requirements  must  be  considered  from  the 
beginning  by  the  user  and  developer  in  relation  to  all 
other  system  requirements.  The  Program  Manager 
should  have  this  in  mind  as  the  program  progresses 
from  a Required  Operational  Capability  through  the 
system  specification  to  the  computer  program  speci- 
fications. He  should  insist  on  the  participation  of  the 
user  in  all  design  reviews. 


Requirements  must  be  defined  early  and  with 
specificity.  In  the  case  of  requirements  that  cannot 
be  defined  at  the  start,  a schedule  for  such  definition 
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should  bt  established  and  the  software  planned  in 
accordance  with  the  schedule.  Too,  the  Program 
Manager  should  plan  the  development  schedule  to 
accommodate  changing  requirements.  He  should 
remember  that  software  is  affected  by  nearly  every 
change  in  the  weapon  system  design.  (Bartlett, " p 
6). 

The  latter  statement  suggests  another  point:  the 
integration  of  hardware  and  software  requirements. 
One  aspect  of  this  is  the  software/computer  relation- 
ship. Obviously,  the  computer  can  have  a big  effect 
on  the  software,  but  the  reverse  effect  may  be  even 
greater.  The  use  of  higher  order  languages  is  being 
promoted  for  development  of  defense  software  al- 
though the  use  of  a higher  order  language  is  some- 
times less  efficient  in  terms  of  the  required  memory 
capacity  and  the  speed  of  the  computer.  (Aviation 
Week,  p 41).  The  issue  here  for  the  Program  Man- 
ager is  to  ensure  that  his  systems  engineering  people 
plan  for  the  fact  that  perhaps  a larger,  faster  ma- 
chine is  required  if  the  software  cost,  schedule,  or 
performance  (or  all  three)  are  not  to  be  adversely 
affected.  One  recommendation  of  the  DOD  Weapon 
Systems  Software  Management  Study,  conducted  by 
Johns  Hopkins  University,  was  to  require  that  com- 
puter systems  be  sized  to  provide  for  uncertainties 
and  requirement  growth.  As  stated  (Johns  Hopkins,1 

p 6-22): 

“...It  is  a basic  feature  of  software  that  it  can 
accommodate  change  provided  it  is  not  limited  by 
hardware  capacity  or  speed.  Accordingly,  an  im- 
portant part  of  software  systems  engineering  is  the 
judicious  and  controlled  provision  of  growth 
capability.” 

Aside  from  the  software-computer  relationship, 
there  is  the  larger  relation  of  software  to  total  system 
requirements.  In  Government  Executive,  August 
1975,  General  Phillips,  the  Commander  of  the  Air 
Force  Systems  Command  was  quoted  as  saying: 

"We  have  come  to  the  conclusion  that  we  must 
engineer  software  in  much  the  same  way  we  engi- 
neer hardware. ..What  all  this  boils  down  to  is  a 
full  systems  engineering  approach  to  software 
development.” 

The  process  of  applying  system  engineering  to  a 
requirements  definition  is  often  referred  to  as  Sys- 
tems Requirements  Analysis.  The  effective  use  of 


Systems  Requirements  Analysis,  particularly  as  it 
relates  to  software,  is  an  area  to  be  pursued  by  the 
Program  Manager.  (Bartlett,  p 14). 

The  effects  of  an  adequate  or  inadequate  require- 
ments analysis  or  definition  ripple  through  all 
phases  of  software  development,  including  design. 
Changes  in  requirements  cause  changes  in  design 
and  these  in  turn  usually  cause  schedule  changes. 
(Software  changes  continue  throughout  a project  for 
a number  of  reasons  including:  requirements 
changes,  hardware  deficiency  accommodation  and 
new  or  modified  interfaces.  (TRW,  p 1-2)). 
Changes  in  schedule  will,  at  a minimum,  increase 
costs,  and  may  preclude  the  meeting  of  all  perfor- 
mance requirements.  Ideally,  every  step  should  be 
completed  prior  to  starting  the  next.  According  to 
Eldon  R.  Mangold: 

“From  a management  standpoint,  it  is  essential 
that  the  successive  steps  in  the  development  proc- 
ess be  restricted  until  the  preliminary  design  is 
completed. " (Mangold, ' p 2—1 3). 

In  some  programs,  schedules  have  been  so  tight 
that  coding  was  begun  before  an  adequate  analysis  of 
program  design  could  be  performed.  (TRW,  p 
5-24).  Again,  the  Program  Manager  must  exert 
every  effort  to  protect  the  program  against  the  cost 
and  schedule  impacts  of  changes.  Two  areas  where 
the  Program  Manager  can  accomplish  this  are,  first, 
in  planning  and  secondly,  in  configuration 
management. 

“The  planning  of  a computer  program  develop- 
ment is  probably  the  source  of  fifty  to  seventy-five 
percent  of  all  development  problems.  Planning 
does  not  have  to  be  bad  to  lead  to  problems;  but  it 
must  be  exceptionally  good  to  avoid  them."  (Bart- 
lett,'" p 10). 

The  above  quote  serves  to  emphasize  the  impor- 
tance of  planning.  Planning  pervades  the  entire 
development  process.  Substantive,  early  planning 
can  assist  in  the  avoidance  of  problems  by  providing 
schedule  flexibility,  and  adequate  computer  size. 

The  application  of  configuration  control  to  soft- 
ware is  not  new.  but  deserves  top  management 
attention  because  of  its  importance  during  build  up 
of  the  architecture  and  logic  as  well  as  later.  One  of 
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the  problems  with  software  management  in  the  past 
has  been  that  software  was  treated  simply  as  data, 
not  as  a deliverable  contract  line  item  and  thus  did 
not  get  the  same  visibility  as  did  hardware.  The 
Johns  Hopkins  study  recommended  that  major  com- 
puter software  involved  in  weapon  systems  develop- 
ment be  designated,  during  full  scale  development, 
as  configuration  items  and  deliverables  to  include: 

1 ) operational  software; 

2)  development  support  software,  and 

3)  test  and  integration  software.  (Johns  Hopkins,1 
pp  2-5,  2-11). 

The  Air  Force  has  taken  steps  to  implement  this 
recommendation. 

Formal  configuration  management  of  software 
begins  with  the  approval  of  the  development  specifi- 
cation that  occurs  about  the  time  of  preliminary 
design  review.  The  preliminary  design  review  also 
provides  the  first  clear  look  at  the  software  design 
and  reflects  the  matching  of  the  requirements  to  the 
design.  Although  the  Program  Manager  cannot  be 
expected  to  attend  every  design  review  in  his  pro- 
gram, he  should  stress  the  importance  of  these 
reviews  to  his  software  manager. 

IMPLEMENTATION 

Implementation  is  the  step  during  which  the  de- 
sign is  converted  to  program  code  and  debugged  (or 
tested)  to  eliminate  any  errors  that  may  exist  (there 
will  be  errors).  The  analysis  and  design  phase,  al- 
though not  easy  to  track,  has  some  visible  means  of 
measuring  progress  that  are  similar  to  those  for 
hardware  (written  requirements,  flow  charts,  an 
analysis  and  design  specification,  etc.).  The  imple- 
mentation phase  poses  different  problems;  it  is  diffi- 
cult to  find  an  appropriate  way  of  determining 
status.  Quoting  (Johns  Hopkins,'  p 2-6): 

“The  abstract  nature  of  software  makes  it  difficult 
to  measure  progress  and,  hence,  makes  it  even 
more  necessary  to  formalize  the  steps  in  design, 
implementation,  and  test.  The  lack  of  such  defini- 
tion leads  to  difficulties  in  interface  management 
and  to  the  late  discovery  of  inadequate  require- 
ments or  design  errors,  with  resulting  slippages  in 
schedules  and  increases  in  cost." 


Problems 

There  are  two  basic  problems  involved  here.  One, 
it  is  the  inclination  of  programmers  to  do  the  inter- 
esting work  at  the  expense  of  dull  work 
(documentation).  Visible  signs  of  programming 
progress  are  almost  totally  lacking.  Another  set  of 
difficulties  arises  from  the  nature  of  the  product. 
There  are  virtually  no  objective  standards  or  mea- 
sures by  which  to  evaluate  the  progress  of  computer 
program  development.  (Wolverton,"  p 1).  Because  of 
this  situation  we  have  what  is  known  as  the  90 
percent  syndrome.  (Aviation  Week, ' p 42).  This  is 
expressed  in  Golub’s  Law  #12  that  says: 

“...projects  progress  quickly  until  they  are  90 

percent  complete,  and  then  they  remain  90  per- 
cent complete  forever.”  (Grooby,'  p 252).* 

The  Program  Manager  has  several  means  at  his 
disposal  for  tracking  cost  and  schedule  in  any 
project.  Among  these  are  the  Cost  Performance 
Report  (CPR)  and,  for  smaller  programs,  the 
Cost/Schedule  Status  Report  (C/SSR).*  ‘ In  the  past 
these  means  have  not  been  satisfactory  for  obtaining 
software  visibility  primarily  because  software  was 
treated  as  “data”  and/or  was  so  low  on  the  Work 
Breakdown  Structure  (WBS),  if  there  at  all,  that  it 
was  never  seen. 

Milestones 

The  recommendation  has  been  made  that  software 
be  put  in  the  WBS  at  a level  equivalent  to  a hardware 
subsystem.  (Borklund, " p 31,  Johns  Hopkins,  1 p 
2-4).  This  would  increase  the  visibility  and  under- 
standing of  software. 

The  question  arises:  “Is  the  CPR  or  C/SSR  type 
information  on  software  meaningful,  even  when 
available?”  The  CPR  or  C/SSR  information  will 
indicate  whether  the  contractor  is  spending  money 
at  the  rate  he  projected,  but  perhaps  nothing  about 
what  actual  progress  has  been  achieved.  If  some  set 
of  measurable  milestones  is  not  established,  progress 


* This  is  one  of  "Golub's  Laws  of  Computerdom,"  some 
humerous,  but  all  too  true  expressions  of  what  can  go 
wrong  in  computer/software  development. 

**  Discussed  in  detail  in  AFR  800-6  and  AFSC  Pamphlet 
173-3. 
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will  be  measured  in  terms  of  time  or  dollars  ex- 
pended, that  is,  if  100  hours  are  estimated  for  a task 
and  100  hours  have  been  expended  then  the  task  is 
complete.(Kieder  "p  55). The  estimating  of  costand 
schedule  for  software  (coding  in  particular)  has  been 
inaccurate  and  emphasizes  the  need  for  discrete 
milestones  to  evaluate  progress.  A series  of  design 
reviews  (system,  preliminary,  critical)  is  at  least  a 
partial  answer.  In  the  Johns  Hopkins  report  mile- 
stones are  discussed  and  reference  is  made  to  MIL- 
STD-490,  MIL-STD-483,  and  AFR  800-14,  Vol  II, 
noting  that  milestones  are  indicated  in  these  docu- 
ments but  the  work  to  be  accomplished  and  the 
products  that  are  to  be  delivered  are  not  defined. 
The  Johns  Hopkins  report  did  not  reference  MIL- 
STD-1521,  a Standard  that  does  define  work  and 
deliverables  for  design  review  and  audits. 

One  approach  to  measurement  has  been  proposed 
that  I call  the  "all  or  nothing”  system.  In  this  system 
the  project  is  broken  into  discrete  tasks  (for  example, 
the  coding  of  a module,  component  checkout,  etc.) 
but  attempts  are  not  made  to  estimate  or  measure 
progress  within  the  tasks.  For  any  given  task, 
progress  is  reported  as  either  0 percent  (from  start  to 
almost  finished)  or  100  percent,  the  point  at  which 
the  task  is  physically  complete.  This  approach  takes 
away  the  guesswork  and  eliminates  the  “90  percent 
syndrome.”  The  Program  Manager  should  be  very 
careful  about  how  much  faith  he  places  in  the 
reports  he  receives  (e.g.,  the  CPR  and  C/SSR  re- 
ports are  only  as  valid  as  the  estimates  that  go  into 
them;  and  estimates  for  software  have  been  notori- 
ously inaccurate.) 

VERIFICATION 

Verification  is  the  third  of  three  phases  that  make 
up  the  software  development  process.  Design  is 
established  in  Phase  One.  Phase  Two  is  the  Imple- 
mentation Phase  where  software  is  coded  to  satisfy 
the  requirements,  and  Phase  Three,  the  Verification 
Phase,  determines  whether  or  not  Phase  Two  was 
successful  in  translating  the  requirements  and  de- 
sign into  a computer  program  that  satisfies  the 
operational  needs  of  the  user.  Verification  can  take 
many  forms,  from  a manual  review  of  code  to 
operational  flight  testing.  One  author  describes  veri- 
fication as  three  interrelated  functions.  First  is  Code 
Verification,  the  process  of  determining  whether  the 
actual  code  is  implemented  in  compliance  with  the 


computer  program  specifications.  The  second  func- 
tion is  Validation,  the  process  of  testing  the  coded 
program  against  the  specified  design  and  perfor- 
mance criteria.  The  third  function  is  Certification, 
where  the  testing  process  is  extended  to  an  opera- 
tional (either  real  or  simulated)  environment.  (Reif- 
er, " p 22).  Regardless  of  how  the  verification  phase 
is  defined,  it  is  imperative  that  all  requirements  be 
tested  against  some  measurable  criteria.  A require- 
ment for  which  a feasible  test  does  not  exist  or  for 
which  a test  has  not  defined  should  not  be  allowed. 
(Bartlett,"'  p 6).  The  task  for  the  customer  (and 
therefore  the  Program  Manager)  is  to  ensure  that  all 
requirements  can  be  tested. 

Test  Plans 

To  ensure  that  all  requirements  can  be  tested, 
consideration  of  the  testing  methods  and  criteria 
must  be  accomplished  during  requirements  defini- 
tion. The  Program  Manager  must  ensure  software 
visibility  in  this  process  and  emphasize  its  impor- 
tance to  his  software  people.  The  Program  Manager 
will  not  be  able  to  get  directly  involved  at  the  lower 
levels  of  detail,  but  he  can  influence  attention  to 
software  through  insistence  on  thorough  planning. 
Software  test  plans  must  be  written  to  the  same  level 
of  detail  as  the  requirements  in  the  development 
specifications.  The  test  plans  should  require  that 
each  performance  requirement  of  each  computer 
program  configuration  end  item  be  verified  in  some 
appropriate  manner.  Acceptance  criteria  should  be 
specified.  (Richards,  ‘p  68). 

Independent  Verification 

The  discussion  of  software  verification  to  this 
point  has  been  restricted  to  that  done  by  the  devel- 
oping contractor.  An  adjunct  to  verification  by  the 
developing  contractor  is  the  use  of  an  independent 
verification  contractor — an  excellent  means  of  pro- 
viding software  visibility  for  the  Program  Office  and 
the  Program  Manager.  (TRW,"  p 5-9).  This  prac- 
tice originated  with  a requirement  for  the  indepen- 
dent check  of  software  to  insure  nuclear  safety  and  is 
becoming  widespread.  The  practice,  known  as  Inde- 
pendent Validation  and  Verification  (IV&V),  has 
been  expanded  to  include  software  performance  as 
well  as  nuclear  safety  criteria.  When  used  properly, 
the  IV&V  contractor  can  provide  the  Program  Man- 
ager comprehensive  knowledge  of  all  phases  of  soft- 
ware development.  Because  of  having  to  verify  that 
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requirements  have  been  met,  the  IV&V  contractor  is 
in  an  excellent  position  to  provide  feedback  as  to  the 
testability  of  the  requirements  and  the  design  at 
early  design  reviews. 

GENERAL 

Some  additional  means  for  obtaining  software 
visibility,  that  apply  throughout  the  development 
process,  follow. 

Methods  of  Contracting 

The  method  of  contracting  employed  to  obtain 
software  can  have  an  effect  on  the  ability  of  the 
Program  Manager  to  obtain  visibility.  These  me- 
thods of  contracting  include: 

• Selection  of  a single  contractor  to  develop  a 
total  system  with  the  software  treated  as  one  of 
the  contractor’s  several  tasks,  or 

• Selection  of  one  or  more  contractors  to  develop 
the  software  and  another  contractor  to  develop 
the  hardware. 

There  are  other  variations  of  course,  and  there  are 
advantages  and  pitfalls  in  all  of  them.  N.  E.  Bolen, 
writing  in  "An  Air  Force  Guide  to  Contracting  for 
Software  Acquisition,"  addressed  the  subject  as 
follows: 

“...The  single  system  contract  has  the  advantage 
of  making  one  organization  responsible  for  system 
performance.” 

"However,  there  is  danger  that  the  software  devel- 
opment effort  will  not  receive  proper  management 
attention  and  resources  within  the  contractor’s 
organization.  (Bolen,1  p 7). 

Under  the  cited  circumstances,  the  Program  Man- 
ager must  take  deliberate  action  to  ensure  software 
visibility  in  development.  Bolen  went  on  to  say: 

“...Dividing  the  system  acquisition  into  separate 
contracts  so  that  one  contractor  is  responsible  for 
software  alone  provides  the  potential  for  better 
Air  Force  visibility  of  the  contractor’s 
progress;...” 

Only  the  potential  for  increased  visibility  is  provided 
by  a separate  software  contract  and  the  practice  is 


not  without  potential  problems.  Among  these  could 
be  a hardware/software  integration  problem  that 
could  place  a considerable  burden  on  the  Program 
Manager’s  organization  and  staff. 

Staffing 

One  of  the  problem  areas  in  software  acquisition 
identified  by  the  Johns  Hopkins  report  was  the 
technical  staffing  of  the  Program  Manager’s  orga- 
nization. The  report  cited  a lack  of  personnel  experi- 
ence in  system  engineering  and  software  develop- 
ment as  contributing  to: 

• Lack  of  policy  guidance  and  planning,  and 

• Inadequate  cost  and  schedule  monitoring. 

The  Program  Manager  should  get  the  best  staff 
possible. 

Aside  from  the  number  and  quality  of  personnel 
on  the  staff,  organization  of  the  staff  can  also  make  a 
difference.  The  ways  of  organizing  vary  widely  from 
vertical,  or  aggregate,  through  matrix.  Also  there 
are  different  forms  of  project  approaches.  Stephen  P. 
Kieder,  in  an  article  entitled,  “Why  Projects  Fail," 
discussed  (what  he  called)  the  “Utilization 
Philosophy”: 

“...A  most  fundamental  problem  which  affects 
many  large  companies  is  one  which  demands 
maximizing  the  utilization  of  personnel,  as  op- 
posed to  a project-oriented  approach.”  (Kieder,  ' 
P 55). 

Kieder  explained  that  he  was  talking  about  the 
reassignment  of  people  whenever  there  is  a lull  in  the 
work  and  the  continuity  problems  that  occur  when 
later  these  people  return  to  a former  job  or  are 
replaced  by  another  person.  In  Kieder’s  words: 

"...This  is  a disastrous  approach  because  while  it 
assures  that  people  are  always  assigned  to  a 
project  and  utilization  is  high,  it  places  an  empha- 
sis upon  effort,  not  results.” 

Although  Kieder's  comments  were  directed  toward 
the  use  of  programmers  in  a large  company,  there  is 
a lesson  to  be  learned  in  terms  of  using  personnel  in 
such  a way  as  to  maintain  continuity  throughout 
any  project.  Keider  also  emphasizes  the  need  to  have 
one  man  responsible  for  the  entire  software  project 
and  not  fragment  responsibilities  to  the  point  where 
no  one  person  is  accountable.  (Kieder.”  p 54). 
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Authority  and  Constraints 

The  high-level  attention  given  to  software  in  re- 
cent years  has  fostered  regulations  and  manuals 
having  the  purpose  of  producing  software  that  satis- 
fies the  constraints  of  cost,  schedule,  and  perfor- 
mance. For  USAF  programs,  these  documents 
cover  the  span  from  Department  of  Defense  Direc- 
tives to  Air  Force  Systems  Command  (AFSC) 
pamphlets. 


The  most  significant  part  of  DODD  5000.29  is 
Section  V,  Policy,  that,  in  general,  states  that  com- 
puter resources  in  Defense  systems  must  be 
managed  as  elements  or  subsystems  of  major  impor- 
tance during  all  phases  of  the  life  cycle  with  particu- 
lar emphasis  on  computer  software. 

To  ensure  the  early  consideration  of  computer 
resource  (including  software)  requirements,  DODD 
5000.29  requires  they  be  included  in  the  DSARC  II  * 
Review.  To  accomplish  this,  DODD  5000.29  lists 
the  following  items  to  be  implemented  in  the  Con- 
cept Formulation  and  Program  Validation  Phases  of 
development: 


DEPARTMENT  OF  DEFENSE 

DIRECTIVES  AND  POLICY 

DODD  5000.1, 

“ Major  System  Acquisitions” 

Department  of  Defense  Directive  5000. 1 does  not 
make  specific  reference  to  software.  This  directive 
establishes  policy  for  the  acquisition  of  major  pro- 
grams (major  programs  are  defined  in  DODD 
5000. 1)  and  management  principles  applicable  to  all 
programs.1’  This  directive  applies  to  software  as 
well  as  to  hardware. 

DODD  5000.29,  “Management  of  Com- ' 
puter  Resources  in  Major  Defense 
Systems” 

This  directive  establishes  policy  for  the  manage- 
ment and  control  of  computer  resources  during 
development,  acquisition,  deployment,  and  support 
of  major  Defense  systems."  The  DODD  5000.29 
applies  to  major  programs  as  described  in  DODD 
5000.1;  in  addition,  the  principles  apply  to  the 
acquisition  of  Defense  systems  that  are  not  in  the 
major  acquisition  category. 

The  DODD  5000.29  is  a relatively  new  document 
(26  April  1976)  and  the  intent  is  that  it  will  not  be  in 
existence  long,  but  that  its  policies  and  principles 
will  be  assimilated  as  an  integral  part  of  the  estab- 
lished process  of  acquiring  major  Defense  systems. 


• Risk  analyses 

• Planning 

• Preliminary  design 

• Security  definition 

• I nterface  control  definition 

• Integration  methodology  definition 

The  risk  areas,  and  a plan  for  their  resolution  shall 
be  included  in  the  Decision  Coordinating  Paper. 

Another  statement  of  policy  is  that  computer 
software  will  be  specified  and  treated  as  a configura- 
tion item. 

To  identify  acquisition  and  life  cycle  planning 
factors  and  guidelines,  a computer  resources  plan 
will  be  developed  prior  to  DSARC  II  and  main- 
tained throughout  the  life  cycle.  (The  Air  Force  plan 
that  meets  this  policy  requirement  is  discussed  un- 
der AFR  800-14,  VolII.) 

In  parallel  with  the  policy  of  making  software  a 
configuration  item  is  the  requirement  to  specify 
unique  software  support  items  as  deliverables  with 
DOD  acquiring  rights  to  item  design  and/or  use. 

Of  particular  interest  to  the  Program  Manager  is 
the  requirement  for  milestone  definition  and  specific 
criteria  to  measure  the  attainment  of  these  mile- 
stones. This  requirement,  of  course,  fits  with  the 
requirement  to  consider  software  as  elements  or 
subsystems  of  major  importance,  and  the  necessity 
to  deal  with  software  as  a configuration  item. 

* Defense  System  Acquisition  Review  Council  It. 
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Another  item  of  policy  which  could  have  a signifi- 
cant impact  is: 

“...DOD  approved  High  Order  Programming 
Languages  (HOLs)  will  be  used  to  develop  De- 
fense system  software,  unless  it  is  demonstrated 
that  none  of  the  approved  HOLs  are  cost  effective 
or  technically  practical  over  the  system  life  cycle.” 
(DODD  5000.29’”  p 3). 

The  DODD  5000.29  has  made  into  DOD  policy 
many  of  the  suggested  solutions  to  software  prob- 
lems that  were  reviewed  in  Part  II  of  this  article.  A 
continuation  of  this  trend  is  foreseen. 

AIR  FORCE  REGULATIONS 

AFR  800-14,  Vol  I,  “Management  of  Com- 
puter Resources  in  Systems” 

This  is  an  especially  important  document  inas- 
much as  it  is  the  first  in  the  series  of  Air  Force 
acquisition  or  management  oriented  regulations  to 
specifically  address  software.  The  stated  objective  of 
AFR  800-14,  Vol  I,  is  to: 

“...insure  that  computer  resources  in  systems  are 
planned,  developed,  acquired,  employed,  and  sup- 
ported to  effectively,  efficiently  and  economically 
accomplish  Air  Force  assigned  missions.” 

In  Section  B of  Vol  I,  the  Program  Manager  is  given 
the  responsibility  to: 

“ Provide  management  and  technical  emphasis  to 
computer  equipment  and  computer  program  re- 
quirements identified  in  the  Program  Manage- 
ment Directive.  ••  (AFR  800-lt,  p3). 


requirement  represents  a significant  departure  from 
previous  practice.  The  policy  has  a ripple  effect  into 
all  aspects  of  software  development.  Also  under  Air 
Force  policy  is  a paragraph  enumerating  those  items 
that  “...Program  Management  Directives  require 
and  Program  Management  Plans  provide  for.” 
(AFR  800-14,  Vol  I,'")-  Some  of  these  items  are: 

a.  Establishment  of  computer  technical  and  man- 
agerial expertise  responsive  to  the  Program 
Office  which  is  independent  of  the  system 
prime  or  the  computer  program  development 
contractor,  and.  is  preferably,  an  organic  capa- 
bility of  the  Program  Office. 

b.  The  specification  and  allocation  of  system  per- 
formance and  interface  requirements  to  be  met 
by ....  computer  programs. 

c.  The  identification  of ....  computer  programs  as 
Configuration  Items. 

d.  Work  Breakdown  Structures  (MIL-STD-881) 
designed  to  facilitate  identification  of  com- 
puter resource  costs. 

e.  Coverage  of ....  computer  programs  during  the 
conduct  of  system  design  reviews,  audits,  and 
management  assessments. 

Each  of  the  five  items  mention  an  area  of  concern 
from  past  software  experience. 

Item  a can  be  interpreted  as  the  charter  for  one 
very  real  way  in  which  the  Program  Manager  can 
provide  for  software  visibility — through  organiza- 
tion. The  Program  Manager  should  exercise  the 
flexibility  given  him  by  AFR  800-2  to  set  up  a 
Program  Office  organization  having  a specific  focal 
point  for  management  of  the  program  software 
efforts.  The  need  for  this  was  noted  by  Kieder  in  his 
article,  "Why  Projects  Fail."  (Kieder.  p 54). 


There  are  several  parts  of  AFR  800-14  that  are  of 
particular  interest  to  the  Program  Manager  from  a 
software  viewpoint.  Under  the  heading  of  Air  Force 
Policy  the  regulation  states: 

“...Computer  resources  in  systems  are  managed  as 
elements  or  subsystems  of  major  importance  dur- 
ing all  life  cycle  phases." 


The  provision  of  AFR  800-14  stated  in  Item  b 
could  be  a fallout  of  the  earlier  stated  policy  of 
software  being  “...elements  or  subsystems  of  major 
importance."  (AFR  800-14,  Vol  I,  p 1).  Because 
the  Program  Manager  cannot  be  expected  to  review 
all  system  and  interface  specifications  it  is  important 
that  the  Program  Management  Plan  provide  for 
proper  treatment  of  software  in  the  systems  engi- 
neering process.  The  importance  of  correct  defini- 
tion of  software  requirements  in  the  systems  engi- 
neering process  is  difficult  to  overemphasize. 
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AFR  800-14,  Vol  II,  “Acquisition  and  Sup- 
port Procedures  for  Computer  Resources  in 
Systems”  (An  Air  Force  Working  Group 
will  review  implementation  of  these 
procedures.) 

Procedures  that  apply  when  implementing  the 
policies  of  AFR  800-14,  Vol  I,  and  other  publica- 
tions that  pertain  to  the  acquisition  and  support  of 
computer  resources,  are  consolidated  in  Vol  II  of 
AFR  800-14.  Volume  II  restates  applicable  portions 
of  related  publications  and  must  be  used  with  those 
publications.  (AFR  800-14,  Vol  II,  p 1-1). 

Planning,  Planning  is  discussed  in  Vol  II  as  it 
relates  to  several  specific  functions.  There  are  three 
planning  functions  in  particular  that  are  software 
peculiar:  The  Computer  Resources  Integrated  Sup- 
port Plan  (CRISP),  the  Computer  Program  Devel- 
opment Plan  (CPDP),  and  the  Computer  Resource 
Working  Group  (CRWG). 

The  Computer  Resources  Integrated  Support 
Plan  identifies  organizational  relationships  and  re- 
sponsibilities for  the  management  and  technical  sup- 
port of  computer  resources.  This  is  a cradle-to-grave 
plan  for  computer  resources  that  assigns  responsibl- 
ity  for  all  areas  of  software  acquisition  and  support. 
As  such,  CRISP  has  great  potential  to  aid  or  hinder 
the  development  of  software  within  the  constraints 
of  cost,  schedule,  and  performance  and  should  re- 
ceive the  effective  backing  of  the  Program  Manager. 

The  Computer  Program  Development  Plan  is  the 
development  plan  for  software.  Preparation  of  this 
plan  is  the  responsibility  of  the  implementing  com- 
mand, but  the  plan  may  be  (and  usually  is)  prepared 
by  the  contractor.  This  is  a complete,  detailed, 
development  plan  and  is  to  contain  items  of  particu- 
lar interest  from  a software  visibility  viewpoint. 
Among  these  items  are  the  contractor’s  develop- 
ment schedule  for  each  Computer  Program  Config- 
uration Item  (and  the  proposed  milestone  review 
points)  and  the  procedure  for  monitoring  and  re- 
porting the  status  of  computer  program 
development. 

The  Computer  Resource  Working  Group  has  as 
its  prime  purpose  the  preparation  of  the  CRISP.  The 
CRWG  is  initially  chaired  by  the  Program  Office 
and  has  representatives  from  the  implementing  and 


supporting  commands.  Because  of  its  membership 
and  its  purpose,  the  CRWG  can  be  very  useful  when 
integrating  requirements  and  in  getting  the  user 
involved. 

Engineering  Management.  Engineering  manage- 
ment as  applied  to  computer  resources  is  described 
in  terms  of  the  system  engineering  process.  One 
objective  of  engineering  management  is  "...that  com- 
puter resources  are  managed  as  an  integral  part  of 
the  total  system.”  (AFR  800-14,  Vol  II,  1 p 4 — 1 ). 

Although  all  reviews  can  aid  in  obtaining  software 
visibility,  one  aspect  of  critical  design  reviews  should 
allow  them  to  provide  additional  visibility,  i.e., 
“...the  CDR  may  be  performed  in  stages  as  the 
logical  design  of  Computer  Program  Components  or 
groups  of  components  is  completed.”  (AFR  800-14, 
Vol  II,  ” p 7-4). 

Testing.  Tests  of  computer  programs  will  be  con- 
ducted under  the  same  general  ground  rules  as 
system  hardware.  (The  principles  of  AFR  800-14 
apply  to  testing  of  computer  resources.)  (AFR 
800-14,  Vol  II,"  p 5-1).  Development  Test  and 
Evaluation  is  divided  into  Configuration  Item  test 
and  system  level  test.  Each  Computer  Program 
Configuration  Item  (CPCI)  must  be  tested  and  es- 
tablished as  a qualified  item  suitable  for  the  system 
level  test. 

Configuration  Management  (CM).  As  specified  in 
AFR  65-3,  CM  will  be  applied  to  each  Computer 
Program  Configuration  Item  throughout  the  system 
acquisition  cycle.  (AFR  800-14,  Vol  II,  p 6-1). 
Volume  II  of  AFR  800-14  is  explicit  in  this  require- 
ment and  requires  that  computer  program  configu- 
ration management  not  be  fragmented  from  the 
overall  system  configuration  management.  Reiter- 
ated are  the  procedures  for  applying  configuration 
management  to  any  part  of  a system  (i.e.,  software 
being  no  different  from  hardware).  One  software 
peculiar  item  is  the  use  of  a Computer  Program 
Identification  Number  (CPIN)  for  each  CPCI.  The 
CPIN  is  assigned  by  Air  Force  Logistics  Command. 

The  identification  of  computer  programs  as  con- 
figuration items  in  recent  years  has  alleviated  one  of 
the  major  software  problems  of  the  past,  specifically 
the  control  of  changes  and  maintenance  of  a known 
baseline.  Software  baselines  are  now  established  and 
changes  are  controlled  through  the  Engineering 
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Change  Proposal  system.  Because  of  the  relative 
ease  with  which  software  can  be  changed  there  is  a 
great  tendency  to  use  software  to  correct 
hardware/design  errors  and  deficiencies  that  be- 
come apparent  late  in  system  development.  This 
usage  takes  advantage  of  one  of  the  inherent  charac- 
teristics of  software  and  is  not  necessarily  wrong. 
There  is,  however,  a danger  of  not  recognizing  the 
great  impact  minor  changes  can  have  on  schedules 
and  costs  owing  to  the  additional,  and  required, 
testing  and  verification. 

Although  the  regulation  states  that  configuration 
management  will  be  applied  to  each  CPCI,  it  does 
not  provide  any  guidelines  as  to  what  computer 
programs  should  be  Computer  Program  Configura- 
tion Items.  In  many  instances  certain  items  of  sup- 
port software  built  by  the  development  contractor 
should  be  designated  deliverables  (and  CPCI)  in 
addition  to  the  operational  software.  This  support 
software  may  be  either  that  required  for  support 
during  the  production/deployment  phases,  or  soft- 
ware tools  usable  in  the  development  of  other  opera- 
tional software.  The  Program  Manager  should  en- 
sure that  his  staff  is  aware  of  his  policy  on  support 
software  and  that,  when  appropriate,  such  software 
is  designated  as  a Computer  Program  Configuration 
Item(s). 

Documentation.  Documentation  is  needed  during 
development  to  track  progress  and  provide  informa- 
tion for  management  visibility  and  decision  making. 
(AFR  800-14,  Vol  II,  ' p 7-1).  This  statement 
emphasizes  one  of  the  more  important  aspects  of 
software,  i.e.,  the  only  way  to  see  progress  in  soft- 
ware (or  the  end  product)  is  through  documenta- 
tion. This  is  not  true  of  data.  Data  management  in 
general  is  handled  through  a data  management 
office  in  accordance  with  AFR  310-1  and  through 
the  use  of  techniques  such  as  deferred  ordering, 
deferred  requisitioning  (described  in  AFR  310-1 
and  Armed  Services  Procurement  Regulation 
ASPR,  Section  7),  and  an  accession  list. 

Volume  II,  AFR  800-14  lists  five  categories  of 
documents  usually  prepared  by  the  contractor  and 
used  for  performance  monitoring:  Configuration 
management,  engineering,  test,  operation,  and  sup- 
port. Of  particular  interest  are  specifications  (engin- 
eering documents),  because  they  document  require- 
ments and  the  actual  computer  program  as  coded. 
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Computer  program  specifications  are  written  in  ac- 
cordance with  MIL-STD-490,  MIL-STD-483,  and 
MIL  - S - 83490.  To  quote  from  AFR  800-14,  Vol- 
ume II: 

"Specifications  provide  the  basis  for  documenting 
requirements,  controlling  the  incremental  devel- 
opment between  major  program  milestones  and 
providing  visibility.” 

Contractual  Requirements.  Contractual  require- 
ments  are  discussed  in  the  regulation  but,  while 
different  means  of  including  software  in  the  contract 
for  a prime  contractor  are  described,  mention  is  not 
made  of  the  possibility  of  a separate  contract(s)  for 
software.  The  point  is  made  that  the  Program  Man- 
ager should  ensure  that  instructions  to  those  who 
bid  provide  for  preliminary  contractor  plans  that 
describe  the  computer  program  development 
concept. 

Computer  programs  should  be  identified  at  Level 
Three  in  the  project  Work  Breakdown  Structure. 
This  statement  is  of  major  significance  to  the  Pro- 
gram Manager.  In  a major  program  particularly, 
such  as  an  airplane  or  a missile  system,  placing 
software  at  Level  Three*  of  the  project  WBS  could 
pose  some  problems  as  well  as  provide  some  real 
benefits.  On  the  benefits  side: 

“Identification  of  computer  program  configura- 
tion items  at  Level  Three  of  the  WBS  will  provide 
the  visibility  necessary  to  evaluate  cost,  schedule, 
and  performance  of  contractor  efforts.”  (AFR 
800-14,  Vol  II,"  p 8-2). 

Conversely,  if  there  is  a large  amount  of  software, 
consisting  of  several  computer  programs  associated 
with  different  hardware  (and  perhaps  being  devel- 
oped by  different  contractors)  placing  all  software  at 
Level  Three  of  the  WBS  might  not  be  feasible  nor 
desirable.  It  might  be  quite  difficult  to  correlate  the 
WBS  and  the  specification  tree  with  the  actual 
manner  of  software  procurement. 


* MIL  STD  88 1 A,  “Work Breakdown  Structures  for  Defense 
Material  Items.”  has  a series  of  appendices  that  show  a 
summary  Work  Breakdown  Structure  for  several  types  of 
systems  (e.g.,  aircraft,  missile,  electronics).  The  only  sys- 
tems for  which  software  (computer  programs)  is  listed  at 
Level  Three  of  the  WBS  is  electronics  systems.  Software  is 
not  shown  at  all  in  the  other  system's  WBS. 


In  the  regulation  AFR  800-14,  Vol  II,  software  is 
discussed  as  a contract  deliverable.  The  statement  is 
made  that  "contract  deliverables  are  specified  as  line 
items  in  the  contract,”  and  that  "while  computer 
programs  and  documentation  must  be  listed  on  the 
DD  1423,*  the  DD  1423  should  be  identified  as  an 
exhibit  or  attachment  depending  on  the  required 
management  emphasis.”  (AFR  800-14,  Vol  II,"  p 

8- 2).  An  AFSC  supplement  to  the  ASPR,  Section 

9- 603,  expands  on  this  direction.  This  supplement 
also  requires  computer  software/computer 
programs/computer  data  bases  to  be  specified  as 
line/subline  items  in  the  contract  schedule.  There  is 
still  a dual  treatment  of  software  as  a line  item  and  as 
“data”.  This  is  handled  by  requiring  that  delivery  of 
computer  software/computer  program(s)/computer 
data  base(s)  documentation  be  specified  on  separate 
DD  Forms  1423  — DD  Forms  1423  separate  from 
those  that  specify  the  actual  cards,  tapes,  etc. 

OTHER  GOVERNING  DOCUMENTS 

AFSC  Pamphlet  800-3,  “A  Guide  for  Pro- 
gram Management” 

The  general  considerations  involved  in  managing 
the  acquisition  of  a system  are  described  in  AFSCP 
800-3.  The  pamphlet  is  intended  as  a guide  and  does 
not  specify  inflexible  procedure  through  which  all 
program  goals  are  achieved.  (AFSCP  800-3,"'  p 
1-1).  The  acquisition  process  is  traced  through  its 
different  phases,  and  a general  description  of  the 
principal  functions  involved  in  managing  systems 
acquisition  programs  is  given.  The  portions  of  the 
AFSC  Pamphlet  800-3  that  are  of  interest  to  the 
Program  Manager  from  a software  peculiar  view- 
point follow.  ** 

• A System  Design  Review  should  address  the 
allocated  requirements  for  computer  programs 
and  interfacing  equipment.  (AFSCP  800-3,"  p 
8-5). 

* Department  of  Defense  Form,  DD  1423. 

•*  Chapter  8,  “Engineering  Management,”  mentions  com- 
puter programs  several  times  to  emphasize  differences 
between  hardware  and  software  and  points  out  peculiarities 
of  software  in  the  systems  engineering  process. 


• In  the  discussion  of  Critical  Design  Reviews, 
AFSCP  800-3  states  the  purpose  of  a CDR  for 
a CPCI  is  to  establish  the  integrity  of  computer 
program  design  at  the  level  of  flow  charts  or 
computer  program  logical  design  prior  to  cod- 
ing and  testing.  (AFSCP  800-3,  p 8-5).  This 
view  of  the  CDR  in  relation  to  the  software 
development  process  is  an  idealistic  one.  In 
practice,  the  exigencies  of  schedule  and  money 
will  often  force  coding  to  start  prior  to  CDR. 
In  fact,  some  software  managers  consider  the 
CDR  as  a logical  event  to  separate  coding  from 
the  start  of  validation/verification. 

• Under  the  heading  entitled,  “Configuration 
Management,"  software  is  mentioned  only  to 
the  extent  of  pointing  out  that  the  selection  of 
Configuration  Items  below  prime-item  level  is 
a management  decision  accomplished  through 
the  systems  engineering  process  and  that  each 
computer  program  is  identified  and  docu- 
mented by  one  macro  flow  chart.  (AFSCP 
800-3,“  p 9-4). 

• "Data  Management  is  the  only  chapter  that 
has  a section  devoted  to  software.  This  section 
of  AFR  800-3  lists  several  things  to  be  ad- 
dressed in  determining  how  to  satisfy  opera- 
tional requirements.* 

In  Chapter  16  great  emphasis  is  placed  on  the  role  of 
the  Program  Manager  in  acquisition  of  computer 
programs.  I quote 

"Early  identification  of  computer  resources,  and 
technical  and  management  expertise  within  the 
Program  Offices  is  needed  to  manage  and  engineer 
the  acquisition  of  functional  subsystems  that  in- 
corporate computer  programs.  The  Program 
Manager  must  provide  the  management  expertise 
to  focus  attention  on  computer  program  develop- 
ment and  integration  across  the  total  system." 
(AFSCP  800-3."  p 16-8). 


* SectionD,  Chapter  16.  is  titled,“Acquisition  and  Support  of 
Computer  Programs."  I feel  this  section  has  been  placed  in 
the  wrong  chapter  and  the  AFSCP  800-3  should  be  revised, 
in  accordance  with  the  guidelines  of  AFR  800-14  and  the 
ASPR.  to  show  that  computer  program  are  nof  data. 
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PART  IV 

Summary  and  Observations 

As  software  has  become  a large  segment  of 
weapon  system  development,  the  problems  of  soft- 
ware cost,  schedule,  and  performance  have  become 
critical  to  the  successful  fielding  of  most  weapon 
systems.  The  cost,  schedule,  and  performance  prob- 
lems have  pervaded  all  phases  of  software  develop- 
ment and  have  resulted  from  some  seemingly  un- 
solvable  problems  and  various  sins  of  omission  as 
well  as  commission.  Among  the  more  important 
difficulties  have  been:  (1)  poor  requirements  defini- 
tion; (2)  inadequate  system  engineering;  (3)  inability 
to  track  software  development  progress,  particularly 
during  the  implementation  and  verification  phases; 

(4)  inadequate  change  and  configuration  control 
(hence  changes  drive  costs  and  schedules  beyond 
acceptable  limits);  (5)  improper  matching  of  test  and 
verification  with  requirements;  and  (6)  nonavailabil- 
ity of  support  software  when  needed,  resulting  in 
maintenance  problems  and  higher  maintenance 
costs. 

Software  does  not  have  exclusive  rights  to  these 
problems;  hardware  is  often  subject  to  the  same 
problems.  However,  software  has  been  prone  to  the 
greater  suffering  because  of  the  failure  on  the  part  of 
personnel  having  cognizance  to  recognize  the  im- 
portance of  software.  There  are  ways  to  alleviate 
most  of  the  problems.  If  the  Program  Manager  is 
going  to  control  software  cost,  schedule,  and  perfor- 
mance, he  must  recognize  the  potential  for  problems 
to  occur  and  take  preventative  action.  Significant 
steps  the  Program  Manager  can  take  include: 

(I)  Get  the  user  involved  early.  Require  an 
early  statement  of  user  requirements  and 
meaningful  user  participation  in  design 
reviews. 


(2)  Insist  on  full  incorporation  of  software  into 
the  system  requirement  analysis  process. 
Software  must  be  engineered  as  an  integral 
part  of  the  weapon  system. 

(3)  Place  software  at  a high  level  in  the  WBS 
and  remove  it  from  the  category  of  “data”. 


(4)  Make  full  use  of  planning  aids  such  as  the 
program  management  plan  and  the  CRISP 
to  ensure  all  members  of  the  program 
management  team  know  what  is  expected 
and  required. 

(5)  Make  support  software  a deliverable  item 
and  when  applicable  make  it  a configura- 
tion item.  This  is  particularly  appropriate 
when  software  is  to  be  transferred  to  a 
support  or  using  command. 


(6)  Organize  the  Program  Office  to  provide 
adequate  technical  support  for  software. 
Assign  responsibility  and  accountability  for 
this  support  to  someone  other  than  the 
Program  Manager  who  cannot  be  the 
integrator. 

(7)  Plan  the  total  program  budget  to  provide 
adequate  funds  to  implement  the  total  soft- 
ware development  program. 

One  thing  that  is  present  in  all  aspects  of  what  the 
Program  Manager  must  do  to  obtain  software  is 
planning.  There  is  an  old  saying  in  the  Real  Estate 
Business  that  tells  the  three  most  important  things 
to  consider  when  buying  a house:  location,  location, 
and  location.  An  analagous  comment  on  software 
would  be  that  the  Program  Manager  who  wants 
adequate  software  would  do  well  to  pay  prime 
attention  to  planning,  planning,  and  planning.  Expe- 
rience has  shown  that  if  the  plan  does  not  include 
software  in  the  System  Requirement  Analysis,  it  will 
not  be  included;  if  you  do  not  plan  for  the  use  of  a 
High  Order  Language,  there  may  not  be  enough 
computer  memory  to  handle  the  software;  if  the  plan 
does  not  provide  for  allocation  of  funds  to  support 
proper  software  development,  funds  will  not  be 
available  for  use. 

A primary  point  is  this:  The  Program  Manager 
can  do  little  to  alleviate  problems  of  inadequate 
software  and  lack  of  control  late  in  the  development 
effort.  The  proper  steps  must  be  implemented  in  the 
early  stages  to  assure  the  availabiltiy  of  software  at  a 
later  date.  The  extent  to  which  a Program  Manager 
has  control  of  software  is  a direct  function  of  how 
well  he  plans  for  software  development 
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CONTEMPORARY  MANAGEMENT 
PROFESSIONAL  ASPECTS 


By 

David  D.  Acker,  Professor  of  Management 
Defense  Systems  Management  College 


With  the  forces  of  change  all  about  us,  contemporary  management  must  be 
more  adaptable  than  ever  before.  Proactive  management  is  replacing  traditional, 
reactive  management.  While  retaining  aspects  of  an  art  and  a science,  manage- 
ment is  taking  a professional  orientation  giving  rise  to  the  questions:  “Is 
management  a profession”?  Do  the  practitioners  of  modern  management 
knowingly  “...do  no  harm”?  An  examination  of  professional  standards  reveals 
the  present  position  of  management  in  our  society  and  leads  to  some  interesting 
observations.* 


Evolution  of  Management 


To  separate  the  evolution  of  management  as  a 
discipline  from  the  evolution  of  society  in  general 
would  be  difficult,  if  not  impossible.  I have  not 
attempted  to  so  do. 

The  question  is  whether  management  may  be 
considered  a profession.  To  some,  management  may 
appear  to  have  passed  through  the  evolutionary 
stages  of  an  art  and  a science  and  to  have  gained 
recognition  as  a profession.  This  may  be,  but 
management  retains  aspects  of  an  art  and  a science. 
Like  an  art,  management  involves  the  application  of 
personal  and  conceptual  skills;  like  a science,  it 
involves  the  application  of  technical  skills  (methods 
and  principles). 

First,  examine  the  term,  “art.”  Any  worthwhile 
human  endeavor  normally  comes  into  existence  as 
an  art.  Art  is  simply  the  deliberate  application  of 
skills  and  knowledge  to  accomplish  some  end.  If  this 


‘Based  on  a paper  presented  by  Mr.  Acker  at  the  Winter  Annual 
Meeting,  American  Society  of  Mechanical  Kngineers,  New  York, 
NY,  6 Dec  76. 


definition  is  applied  to  the  activities  of  management, 
there  is  good  cause  for  viewing  management  as  an 
art. 

Second,  consider  the  term,  “science."  Examina- 
tion reveals  science  to  be  motivated  by  a need  to 
better  understand  the  foundation  upon  which  art 
rests.  Science  is  the  search  for  new  knowledge 
through:  (a)  a rigorous  method  of  data  collection, 
classification,  and  measurement;  (b)  the  establish- 
ment of  hypotheses;  and  (c)  the  testing  of  hy- 
potheses. Management  has  placed  increased  empha- 
sis on  the  use  of  scientific  theory  and  practice.  This 
has  led  to  new  knowledge.  Thus  management  has 
rightfully  been  called  a science.  At  this  point,  art  and 
science  are  recognizable  as  complementary 
concepts. 

Third,  note  the  term,  “profession.”  Close  scrutiny 
reveals  this  term  to  be  an  occupation  requiring  the 
application  of  a high  level  of  education  and  intellec- 
tual skills.  A profession  then,  is  a calling  requiring 
specialized  knowledge,  following  long  preparation. 
The  life  work  of  a doctor,  lawyer,  theologian  or 
engineer  falls  within  this  definition.  Yet,  I believe 
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the  term  encompasses  an  even  deeper  connotation — 
a connotation  that  is  apparent  when  the  term  is 
applied  to  the  so-called  learned  professions  of  medi- 
cine, law  and  the  ministry.  In  essence: 

• There  is  a matter  of  public  responsibility.  A 
professional  is  considered  by  the  public  to  be  a 
person  who  is  qualified  by  education  and  expe- 
rience to  practice  in  his*  field  as  he  carries  out 
his  assignment  in  an  authoritative  and  respon- 
sible manner. 

• There  is  the  requirement  for  continuing  educa- 
tion. In  our  society  education  has  become  a 
continuing  process  for  the  professional — a 
process  that  does  not  terminate  with  award  of  a 
baccalaureate  degree.  The  professional  must 
keep  atuned  to  progress  in  his  field  of  expertise. 

Fourth,  examine  the  term,  “manager.”  A man- 
ager is  revealed  to  be  a person  who  conducts  busi- 
ness with  frugality  and  care.  According  to  Drucker, 
he 

“...develops  people.  Through  the  way  he 
manages  he  makes  it  easy  or  difficult  for  them 
to  develop  themselves.  He  directs  people  or 
misdirects  them.  He  brings  out  what  is  in  them 
or  he  stifles  them.  He  strengthens  their  integ- 
rity or  he  corrupts  them.  He  trains  them  to 
stand  upright  and  strong,  or  he  deforms 
them — whether  he  knows  it  or  not.  He  may  do 
them  well,  or  he  may  do  them  wretchedly.  But 
he  always  does  them."' 

The  discipline  of  management  has  been  evolving 
and  changing  dramatically  over  the  past  75  years.  In 
this  period,  there  has  been  a remarkable  series  of 
changes  in  management  concerns  and  charac- 
teristics. 

From  1900  to  World  War  I,  management’s  princi- 
pal concern  was  with  organization  for  production. 
This  was  the  period  of  man  vs  nature  when  the 
primary  resource  was  raw  material  and  the  primary 
requirement  for  management  was  that  of  property 
management.  Management  was  basically  role- 
oriented. 

•Referred  to  in  masculine  terms  although  the  feminine  is  under- 
stood to  apply. 


From  World  War  I to  1950,  management’s  princi- 
pal concern  turned  :o  the  organization  of  organiza- 
tions. In  this  period  of  man  vs  machine  the  primary 
resource  was  technology — the  primary  requirement 
for  management  was  experience.  Management  was 
basically  product-oriented. 

From  1950  to  1975,  management  was  concerned 
with  the  organization  of  processes.  In  this  period  cf 
man  vs  man  the  primary  resource  was  knowledgt 
and  expertise.  The  primary  management  require- 
ments were  education  and  technical  competence. 
Management  was  principally  service-oriented. 

We  now  look  to  the  1980  to  2000  period.  It  will  be 
a period  of  man  vs  time,  with  time  serving  as  the 
principal  resource.  Management  will  be  concerned 
with  basic  beliefs  and  values.  The  survival  of  our 
present  pluralistic  society  may  depend  upon  manag- 
ers’ expertise,  performance,  sense  of  dedication,  and 
standards  of  value. 

Professional  Standards 

The  preceding  statements  lead  to  the  proposition 
that  management  has  reached  a professional  level. 
Although  "profession"  has  been  interpreted  by  some 
as  being  virtually  synonymous  with  the  term  “occu- 
pation,” it  is  more  widely  recognized  as  an  occupa- 
tion that  meets  a set  of  clearly  defined  standards. 

One  student  of  management,  Sikula,1  states  that 
standards  for  the  professional  manager  should 
include: 

• A specialized  body  of  knowledge; 

• Formal  educational  programs; 

• Societies  and  representative  professional 
organizations; 

• An  ethical  code  of  conduct; 

• Established  fees  for  service — with  service  re- 
maining in  priority  ahead  of  the  quest  for 
economic  reward;  and 

• A central  accreditation  or  licensing  agency. 

Using  these  criteria  as  a basis,  it  is  possible  to 
determine  the  status  of  management  in  contempo- 
rary society. 
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ANALYSIS  OF  THE  STANDARDS 

A specialized  body  of  knowledge  devoted  to  the 
subject  of  management  does  exist.  The  knowledge 
evolved  as  management  developed  as  a discipline. 
Some  believe  this  body  of  knowledge  is  not  orga- 
nized nor  systematic;  others  refute  this  statement. 
Suffice  it  to  say,  there  are  management  concepts  and 
principles.  Complete  agreement  has  not  been 
reached  as  to  what  these  concepts  and  principles 
include. 

Formal  educational  programs  are  available  to 
managers.  College  students  can  major  in  several 
fields  of  management.  Many  colleges  now  offer 
advanced  degrees  in  specialized  management  fields. 
Large  companies  and  the  military  services  offer 
internal  management  development  programs.  Prac- 
ticing managers  participate  in  extension  courses, 
short  courses,  seminars,  and  workshops  to  increase 
their  knowledge  and  update  managerial  skills.  There 
are  a few  successful  managers  who  have  not  had 
formal  education.  For  the  most  part,  the  latter 
managers  received  their  education  at  the  "College  of 
Hard  Knocks,"  i.e.,  through  practical  experience. 
Management-oriented  societies  and  professionally 
oriented  divisions  within  other  professional  groups 
do  exist. 

Two  of  the  best  known  management-oriented  or- 
ganizations are  the  American  Management  Associa- 
tion and  the  National  Academy  of  Management. 
The  former  organization  is  composed  of  manage- 
ment practitioners,  while  the  latter  organization  is 
made  up  of  management  academicians.  An  example 
of  a professionally  oriented  division  within  one  of 
the  societies  would  be  the  Management  Division 
within  the  American  Society  of  Mechanical  Engi- 
neers (ASME).  An  analysis  of  other  professional 
management  organizations  reveals  a primary  con- 
cern with  the  interests  of  specialized  management 
groups,  such  as  program  managers,  financial  man- 
agers, production  managers,  and  personnel 
managers. 

Codes  of  conduct  are  being  developed  by  manage- 
ment organizations.  This  is  evident  in  current  re- 
search reports  and  the  literature  developed  and 
disseminated  by  these  organizations  There  is  an 
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even  stronger  move  afoot  to  focus  on  managerial 
values,  social  responsibility,  and  ethical  behavior. 

Managers  do  charge  fees.  The  fees  may  be  col- 
lected as  salaries  or  as  compensation  for  consulting 
services.  Whether  or  not  service  or  compensation  is 
the  manager's  primary  motivation  can  only  be  an- 
swered by  the  manager  himself. 

Today,  a central  accreditation  or  licensing  agency 
for  professional  managers  is  nonexistent.  In  this 
regard,  management  has  not  reached  full  profes- 
sional status.  So-called  “managers”  are  not  required 
to  meet  any  standards  or  to  pass  any  uniform  exami- 
nation before  assuming  a management  position  in  an 
organization.  In  a very  broad  way,  a college  that 
offers  an  undergraduate  and  graduate  degree  in 
management  might  be  considered  a form  of  accredi- 
tation agency.  However,  the  standards  established 
by  colleges  are  not  uniform  even  though  the  colleges 
having  such  standards  may  have  passed  some  form 
of  accreditation  inspection  by  a professional  orga- 
nization. Furthermore,  general  agreement  has  not 
been  reached  as  to  whether  or  not  a central  accredi- 
tation or  lice;. sing  agency  for  managers  is  either 
necessary  or  desirable. 

OTHER  CONSIDERATIONS 

Albers'  simple  definition  of  a professional  appears 
reasonable  and  could  serve  as  the  basis  for  a stan- 
dard. He  says  that  a professional  is  one  who  has 
committed  himself  to  “the  learning  of  a systematic 
body  of  knowledge  together  with  the  skills  necessary 
for  application  and  conformity  to  an  established 
body  of  standards."’ 

It  appears  reasonable  to  define  professional  in 
terms  of  a continuum — placing  the  ideal  profes- 
sional at  one  end  and  unorganized  occupations  at 
the  other  end.  This  approach  is  probably  better  than 
establishing  a unique  set  of  characteristics  against 
which  one  has  to  make  a measurement  on  an  all-or- 
nothing  basis.  The  essential  characteristics  of  a 
model  professional  can  be  readily  identified  using 
the  continuum  approach. 

According  to  Vollmer  and  Mills,  the  professional: 

• Performs  in  accord  with  a systematic  body  of 
knowledge; 
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• Has  authority  that  is  based  upon  superior 
knowledge; 

• Has  broad  social  sanction  and  approval  to 
exercise  authority; 

• Functions  in  compliance  with  a code  of  ethics; 
and 

• Has  a culture  that  is  sustained  by  an  organiza- 
tion—an  association  of  professionals.4 

Managers  may  not  have  developed  the  above 
characteristics  to  the  same  extent  as  traditional 
professional  groups;  however,  Kast  and  Rosenzweig 
believe, 

“If  we  view  the  concept  of  professionalism 
on  a continuum,  it  is  apparent  that  the  trend  (in 
management)  over  the  past  several  decades  has 
been  toward  greater  compliance  with  these  ele- 
ments of  professionalism.”’ 

The  Professional  Aspects 
of  Military  Management 

Man  advances,  or  regresses,  within  the  structure 
of  his  society.  Thus,  it  can  be  quickly  determined 
that  military  officers  have  achieved — as  have  their 
civilian  counterparts — some  degree  of  professional 
status.  In  the  military  society,  knowledge  and  skills 
are  acquired  at  the  service  academies.  Upon  this 
foundation  professional  character  in  the  military 
services  is  built.  Beyond  this,  military  officers  re- 
ceive periodic,  intensive  formal  education  through- 
out their  careers. 

Huntington,4  believes  the  distinguishing  charac- 
teristics of  a professional  military  officer  are  exper- 
tise, responsibility,  and  corporateness.  Isn't  this  also 
true  of  the  professional  manager  in  the  civilian 
sector?  The  manager — be  he  military  or  civilian — is 
an  expert  possessing  specialized  knowledge  and  skill 
in  a significant  field  of  human  endeavor.  Pockling- 
ton,7  describes  our  military  officers  as  responsible 
experts,  working  in  a social  context  and  performing 
services  that  are  essential  to  the  functioning  of 
society.  These  officers  are  members  of  a corporate 
group,  a group  that  shares  a unique  social  responsi- 
bility. In  describing  military  officers  as  profession- 
als, Pocklington  adds  that  apart  from  the  three 


elements  of  professionalism,  a distinct  sphere  of 
military  competence  also  exists. 

MARKS  OF  A 

“PROFESSIONAL”  MANAGER 

A universal  concept  of  management  is  that  in  its 
applied  aspects,  management  is  the  practice  of  get- 
ting things  done  through  others.  The  true  marks  of  a 
"professional"  manager  are  reflected  in  how  well  he 
accomplishes  this  task.  This  recognition  does  not 
come  about  as  a result  of  legal  registration.  An 
accomplished  manager  brings  to  his  employer  (or 
client) 

“...a  competence  that  is  sufficient  for  the 
assignment  (at  hand),  an  eagerness  to  serve,  a 
dedication  to  the  task,  an  appreciation  of  costs, 
a sense  of  timing,  a desire  to  communicate,  a 
recognition  of  the  contribution  made  by  others, 
and  the  ability  to  complete  the  assignment  in 
such  a manner  as  to  receive  acceptance  and 
utilization...,  of  the  end  product.”* 

The  manager,  to  be  considered  as  a professional, 
needs  a certain  degree  of  autonomy.  His  employer 
cannot  expect  to  completely  direct,  supervise,  or 
control  him.  Admiral  H.  G.  Rickover,  USN,  once 
said,  “Service  ceases  to  be  professional  if  it  has  in 
any  way  been  dictated  by  a client  or  employer.  The 
role  of  the  professional  man  in  society  is  to  lend  his 
special  knowledge,  his  well-trained  intellect,  and  his 
dispassionate  habit  of  visualizing  problems  in  terms 
of  fundamental  principles  to  whatever  task  is  en- 
trusted to  him.  Professional  independence  is  not  a 
special  privilege  but  rather  an  inner  necessity  for  the 
true  professional  man,  and  a safeguard  for  his  em- 
ployer and  the  general  public.” 

The  manager,  as  a professional,  is  private  because 
he  is  not  subject  to  political  control.  At  the  same 
time,  he  is  public  because  the  welfare  of  his  employer 
establishes  the  limits  of  his  deeds.  The  basic  rule  of 
professional  ethics  set  forth  in  the  Hipprocratic  oath 
of  the  Greek  physician  2500  years  ago — “Above  all. 
not  knowingly  to  do  harm" — is  still  the  basic  rule  of 
the  ethics  of  public  responsibility  Drucker  believes 
that  many  managers  "do  not  realize  that  in  order  to 
be  permitted  to  remain  autonomous  and  private  they 
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have  to  impose  on  themselves  the  responsibility  of 
the  professional  ethic.”’  He  adds,  “...they  still  have 
to  learn  that  it  is  their  job  to  scrutinize  their  deeds, 
words,  and  behavior  to  make  sure  that  they  do  not 
knowingly  do  harm.” 

If  a manager  in  our  present-day  society  assumes 
the  responsibility  that  he  has  been  given,  strives  to 
maintain  an  effective  relationship  with  his  employer 
or  client,  and  carries  out  his  assignment  with  sincer- 
ity and  a true  sense  of  dedication,  his  recognition  as 
a professional  will  follow. 

THE  MANAGER,  PART  OF  A SYSTEM 

Finally,  it  should  be  recognized  that  the  manager, 
although  he  has  a certain  degree  of  autonomy,  is  also 
part  of  a management  system.  This  management 
system  may  be  viewed  as  an  inherently  personal 
process.  It  is  a process  that  takes  place  between  the 
manager  and  his  employer  (or  client)  and  subordi- 
nates. This  relationship  is  most  effective  when  the 
manager  and  his  employer  and  subordinates  have  a 
clear  and  common  understanding  of  the  following: 

• The  role  of  the  manager; 

• The  relationship  of  the  employer/subordinates 
to  the  manager; 

• The  role  of  the  employer/subordinates; 

• What  the  manager  expects  of  his  subordinates, 
i.e.,  the  performance  standards;  and 

• How  the  manager  measures  the  performance 
of  his  subordinates,  i.e.,  the  performance 
appraisal. 

Any  management  system  that  takes  these  issues 
into  consideration  as  a part  of  the  normal  operating 
environment  has  some  of  the  ingredients  for  success. 
In  the  final  analyses  the  key  to  success  is  the  man- 
ager. He  is  the  one  who  must  develop  a management 
•cam,  as  well  as  a system  and  procedures  that  bring 
about,  within  a specified  budget,  timely  results  that 
satisfy  previously  established  objectives  set  forth  in 
well  conceived  plans. 

OVERVIEW 

A most  challenging  intellectual  problem,  that  of 
coping  with  change,  must  be  faced  during  the  last 


quarter  of  this  century.  We  live  in  an  age  of  uncer- 
tainty. Our  society  is  not  stable;  it  is  temporary. 
Alvin  Toffler  believes  we  have  seen  the  death  of 
permanency,  and  that  “...the  individual  must  be- 
come infinitely  more  adaptable  and  capable.. 

All  about  us,  forces  of  change  are  at  work.  The 
need  for  skilled  leadership  is  apparent.  We  are 
groping  to  develop  expertise  in  the  management  of 
social  systems  to  deal  effectively  with  such  things  as: 

• Population  growth,  changing  age  patterns, 
urbanization 

• Economic  instability,  inflation,  bankruptcy 

• Advances  in  science  and  technology 

• New  knowledge,  accelerated  by  proliferation 
of  information 

• New  laws  and  legal  concepts 

• Labor  and  political  unrest 

The  change  in  values,  attitudes  and  behavior, 
according  to  Harland  Cleveland,  call  for  “...new 
kinds  of  organizations,  managed  in  new  ways,  by 
new  kinds  of  people."  To  meet  the  challenge,  tradi- 
tional, reactive  management  (bureaucracy)  is  being 
replaced  by  anticipatory,  proactive  management . 


Final  Observations 

Contemporary  management  is  accepted  as  a disci- 
pline; it  has  yet  to  gain  full  acceptance  as  a profes- 
sion. Perhaps  within  the  next  decade  it  will  be  given 
widespread  acceptance  in  this  respect  by  the  public. 
Professional  status  will  come  about  as  a larger 
number  of  persons  with  education  and  scientific 
expertise  rise  to  responsible  positions  in  the  manage- 
ment hierarchy. 

Managers  might  accelerate  public  acceptance  as 
professionals  if  they; 

• Join  to  contribute  to  the  establishment  of  uni- 
form, high  standards; 

• Provide  service  principally  for  the  benefit  of 
society,  rather  than  for  monetary  gain; 
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• Foster  management  education; 

• Participate  in  the  activities  of  management- 
oriented  societies  or  the  professionally  oriented 
divisions  within  professional  organizations; 

• Answer  the  question  (and  act  accordingly)  as 
to  whether  accreditation  is  desirable  for  those 
who  are  entering  the  field. 

The  challenge  is  clearly  before  our  managers. 
Future  generations  will  receive  the  benefit  if  our 
contemporary  managers  meet  this  challenge  di- 
rectly, enthusiastically,  and  with  a sense  of  purpose. 
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Who  are  the  people  that  make  up  a Congressional  Committee  Staff?  What  is  their 
role  in  the  acquisition  process?  What  are  their  responsibilities  and  what  is  their 
authority?  Do  they,  in  fact,  influence  decisions  in  the  acquisition  process?  And  if  so, 
how?  What  are  the  implications  to  the  program  manager?  These  are  some  of  the 
specifics  addressed  in  this  article. 


PART  I 

INTRODUCTION 


In  recent  years,  the  importance  of  the  professional 
congressional  commitee  staff  member  has  greatly 
increased  in  the  weapon  systems  review  and  ap- 
proval process.  Committee  staff  members  are  in- 
volved heavily  with  both  budgetary  and  technical 
details.  The  committee  staffs  work  primarily  for  the 
committee  chairmen  and  are  in  a position  to  exercise 
considerable  influence  on  the  decision  process.  They 
prepare  committee  members  for  hearings  with  brief- 
ings and  documentation  and  at  times  become  active 
participants  during  the  hearings.  The  extent  of  staff 
influence  depends  upon  the  competence  and  initia- 
tive of  the  individual  staffer.  The  confidence  that  the 
committee  has  in  the  staff  is  directly  related  to  the 
quality  of  the  information  the  staffer  demands,  and 
his  ability  to  interpret  such  information  and  draw 
logical  conclusions.  A program  manager  should 


develop  the  staffs  confidence  through  open,  respon- 
sive, and  forthright  communication.  A most  critical 
aspect  of  the  weapon  system  acquisition  process  is 
the  budgeting  activity  that  culminates  in  congression- 
al approval  of  program  funds.  A congressional  staff 
plays  a very  fundamental  role  during  this  decision- 
making process. 

In  order  for  a program  to  succeed,  it  must  be 
accepted  and  approved  by  the  Congress.  This  in- 
cludes indorsement  and  support  of  the  professional 
staffers  and  the  Armed  Services  Appropriations 
Committee  of  both  the  House  of  Representatives 
and  the  Senate. 


In  the  course  of  the  program  approval  process,  the 
program  manager  may  have  to  appear  as  a witness 
before  the  committees  in  public  or  at  closed  hear- 
ings. Such  appearances  will,  in  most  cases,  be  pre- 
ceded by  a session  with  one  or  more  committee 
staffers.  In  other  cases,  a session  with  a committee 
staff  may  be  the  only  opportunity  the  program 
manager  has  to  defend  his  program  to  the  Congress. 
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Although  this  provision  of  the  law  dealt  only  with 
aircraft,  missile  and  ship  procurement,  the  Congress 
soon  realized  the  desirability  of  expanding  the  re- 
quirement to  other  portions  of  the  DOD  budget. 
Consequently,  there  have  been  seven  additional 
amendments  to  public  law.  A specific  requirement 
now  is  that  research,  development,  test  and  evalua- 
tion (RDT&E);  tracked  vehicles,  personnel 
strengths;  and  other  weapons  procurement  (rifle, 
artillery,  small  arms,  and  torpedoes);  be  subjected  to 
the  annual  authorization  process  prior  to  appropria- 
tion. (Williams,  pp  103-105). 


Congressional  authority  over  the  DOD  budget  is 
rooted  in  the  US  Constitution.  Article  I,  Section  8, 
of  the  Constitution  embodies  in  the  Congress  the 
power  “...to  raise  and  support  Armies...,"  “...to 
provide  and  maintain  a Navy...,”  “...to  make  rules 
for  the  government  and  regulation  of  the  land  and 
naval  forces...,”  and  “...to  make  all  laws  which  shall 
be  necessary  and  proper  for  carrying  into  execution 
the  foregoing  powers.” 

One  “rule”  made  to  “regulate  the  land  and  naval 
forces”  has  been  the  establishment  of  a two-step 
process  whereby  military  programs  are  first  autho- 
rized by  law  and  then,  in  a separate  law,  funds  for 
carrying  out  the  programs  are  appropriated.  This 
process  dates  back  to  1921  when  the  House  of 
Representatives  made  a rule  that  appropriations 
could  not  be  recommended  by  the  Appropriations 
Committee  for  purposes  not  authorized  by  law. 
Similarly,  another  rule  prohibited  the  substantive 
committees  (e.g.,  Armed  Services)  from  adding  ap- 
propriations to  the  reported  authorization  bills. 
(AF/AC*,'  p49). 

APPROPRIATION 


In  1959,  the  two-step  process  began  to  involve  a 
detailed  review  of  the  total  military  budget.  At  this 
time  the  process  was  established  in  public  law  that 
provided: 

“That  no  funds  may  be  appropriated  after  Decem- 
ber 31,  1960  to  or  for  use  of  any  Armed  Forces  of 
the  United  States  for  the  procurement  of  aircraft, 
missiles,  or  naval  vessels  unless  the  appropriation 
of  such  funds  has  been  authorized  by  legislation 
enacted  after  such  date." 

•US  Air  Force,  Office  of  the  Comptroller. 


POSTURE  HEARINGS 

How,  within  this  two-step  framework  of  autho- 
rization and  appropriation  does  the  Congress  meet 
its  Constitutional  obligation?  The  process  begins  in 
January  of  uch  year  when  the  Congress  begins  its 
regular  session.  Before  the  detailed  review  of  indi- 
vidual programs,  the  Armed  Services  Committee  of 
both  the  House  and  Senate  hold  military  posture 
hearings.  The  posture  hearings  usually  cover  only 
broad  aspects  of  the  military  budget  including  force 
structure  and  overall  weapon  and  personnel  strength 
levels.  Witnesses  usually  are  service  officials,  includ- 
ing the  Secretary  of  Defense  and  other  top  OSD 
representatives,  the  Service  Secretaries  and  the  mili- 
tary chiefs. 

AUTHORIZATION 

Posture  hearings  are  followed  by  the  authoriza- 
tion hearings.  The  recent  practice  of  the  respective 
Armed  Services  Committees  has  been  to  hold  sepa- 
rate hearings  on  procurement  and  Research.  Devel- 
opment, Test  and  Evaluation  (RDT&E).  Although 
the  principal  witnesses  at  these  hearings  are  nor- 
mally Assistant  Secretaries  of  the  military  depart- 
ments and  the  military  Deputy  Chiefs  of  Staff,  it  is 
not  unusual  for  a program  manager  to  be  called  to 
testify,  especially  for  designated  major  weapon  sys- 
tems. The  primary  responsibility  of  the  witnesses  is 
to  defend  and  support  specific  programs  outlined 
and  the  funds  requested  in  the  President's  budget 
that  are  being  considered  by  the  Committees. 

Because  of  the  shortage  of  time  as  well  as  the 
desire  for  independent  analysis,  authorization  hear- 
ings are  held  simultaneously  in  the  House  and  Sen- 
ate. However,  because  of  the  statutory  requirement 
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that  money  bills  originate  in  the  House,  the  House 
Armed  Services  Committee  is  the  first  to  complete 
its  review  and  make  any  adjustments  to  the  pro- 
posed budget.  This  process  is  referred  to  as  bill 
“mark  up”.  The  marked  up  bill  is  then  presented  to 
the  full  House  with  a report  containing  the  rationale 
for  committee  action.  Without  waiting  for  the  Sen- 
ate version,  the  House  will  vote  on  the  bill  after  2 or 
3 days  of  floor  debate.  The  Senate  normally  allows 
the  DOD  to  submit  a written  appeal  of  the  House 
action  to  include  the  adverse  impact  of  any  reduc- 
tions imposed  by  the  House.  After  considering  the 
DOD  appeal  and  its  own  analysis  of  the  budget 
request,  the  Senate  Armed  Services  Committee  sub- 
mits to  the  Senate  its  marked-up  version  of  the  bill 
and  a report  containing  rationale  for  committee 
action.  The  full  Senate,  after  floor  debate,  votes  on 
this  bill. 

The  result  of  separate  House  and  Senate  action  is 
two  different  authorization  bills.  These  differences 
are  resolved  in  a conference  committee  made  up  of 
selected  representatives  from  the  respective  Armed 
Services  Committees.  The  conference  committee 
may,  during  deliberation,  consider  only  those  mat- 
ters that  are  in  disagreement.  The  conference  com- 
mittee will  not  reconsider  reductions  agreed  to  by 
both  Houses.  During  this  process  the  DOD  is  once 
again  permitted  to  submit  a written  appeal  from 
actions  under  consideration.  Once  approved  by  both 
Houses,  the  authorization  bill  is  forwarded  to  the 
President  for  signature. 

THi  TWO-STEP  PROCESS 

Meanwhile,  the  second  half  of  the  two-step  proc- 
ess has  already  begun.  The  appropriations  phase 
generally  follows  the  sequence  described  for  author- 
ization but  in  different  committees  and  with  a 
whole  new  set  of  congressional  participants.  '* 

Two  general  conclusions  may  be  drawn  from 
observing  the  legislative  process.  First,  the  process  is 
long  and  involved  and  it  may  take  from  9 to  12 
months  to  complete.  Throughout  the  process  a pro- 
gram manager  may  be  called  to  explain  his  program 
many  times.  He  may  be  required  to  testify  as  an 
expert  witness,  or  he  may  be  tasked  (usually  on  very 
short  notice)  to  provide  written  answers  to  questions 
posed  by  Congressmen,  staffers,  or  other  Govern- 
ment witnesses. 

•Cited  for  further  reading  on  the  legislative  process 


The  second  general  conclusion  drawn  from  ob- 
serving the  legislative  process  is  that  the  heart  of  the 
process  is  committee  activity  — and,  committee 
activity  is  the  province  of  the  professional  staff. 


STAFF  ORGANIZATION  AND 
BACKGROUND 


The  current  concept  of  a professional  committee 
staff  was  established  in  the  Legislative  Reorganiza- 
tion Act  of  1946.  Section  202(a)  of  the  act  provided 
for  “...not  more  than  four  professional  staff  mem- 
bers ...”  on  each  standing  committee  except  Appro- 
priations Committees.  Appropriations  Committees, 
because  of  having  the  greater  oversight  responsibil- 
ity, were  permitted  to  hire  as  many  persons  as  each 
respective  chamber  of  Congress  would  permit. 
(Horn/  p 63).  Expansion  of  committee  staffs  was 
authorized  by  another  reorganization  in  1970.  To- 
day, the  Senate  Armed  Services  Committee  has  a 
total  of  twelve  professional  staff  members,  two  coun- 
selors (lawyers),  and  a chief  counsel  who  serves  as 
staff  director.  The  House  Armed  Services  Commit- 
tee has  eleven  professional  staff  members  and  seven 
counselors,  including  the  chief  counsel.  In  the  Ap- 
propriations Defense  Subcommittees,  the  House  has 
eight  staff  members  assigned  and  the  Senate  has  five. 
(Brownson/p  159ff). 

In  general,  committee  staffs  are  appointed  by 
committee  chairmen.  Although  a staffer  supports  all 
members  of  the  committee,  primary  loyalty  is  to  the 
chairman.  Rieselback,  in  his  commentary  on  con- 
gressional politics,  observes: 

“...the  committee  staff  is  the  creature  of  the  chair- 
man: he  determines  who  will  be  hired,  how  much 
assistance  will  be  provided  for  the  minority  side, 
w hat  the  majority  staff  will  do,  and  often  the  vigor 
with  which  it  carries  out  its  assignments."  (Ries- 
elback/ p 67). 

The  credentials  and  experience  of  professional 
staffers  are  varied,  yet  there  are  many  similarities. 

Many  of  the  staffers  have  been  recruited  from  the 
Executive  Branch  of  the  Government,  including  the 
Department  of  Defense,  "...thus  securing  the  serv- 
ices of  persons  who  are  already  well  versed  in  the 
subject  matter  with  which  the  committee  deals.” 
(Harris,  p 115).  A review  of  the  background  of 
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Congressional  authority  over  the  DOD  budget  is 
rooted  in  the  US  Constitution.  Article  I,  Section  8, 
of  the  Constitution  embodies  in  the  Congress  the 
power  “...to  raise  and  support  Armies...,”  "...to 
provide  and  maintain  a Navy...,"  “...to  make  rules 
for  the  government  and  regulation  of  the  land  and 
naval  forces...,”  and  "...to  make  all  laws  which  shall 
be  necessary  and  proper  for  carrying  into  execution 
the  foregoing  powers.” 

One  “rule"  made  to  “regulate  the  land  a id  naval 
forces”  has  been  the  establishment  of  a two-step 
process  whereby  military  programs  are  first  autho- 
rized by  law  and  then,  in  a separate  law,  funds  for 
carrying  out  the  programs  are  appropriated.  This 
process  dates  back  to  1921  when  the  House  of 
Representatives  made  a rule  that  appropriations 
could  not  be  recommended  by  the  Appropriations 
Committee  for  purposes  not  authorized  by  law. 
Similarly,  another  rule  prohibited  the  substantive 
committees  (e.g.,  Armed  Services)  from  adding  ap- 
propriations to  the  reported  authorization  bills. 
(AF/AC*,'  p49). 

APPROPRIATION 

In  1959,  the  two-step  process  began  to  involve  a 
detailed  review  of  the  total  military  budget.  At  this 
time  the  process  was  established  in  public  law  that 
provided: 

"That  no  funds  may  be  appropriated  after  Decem- 
ber 31,  I960  to  or  for  use  of  any  Armed  Forces  of 
the  United  States  for  the  procurement  of  aircraft, 
missiles,  or  naval  vessels  unless  the  appropriation 
of  such  funds  has  been  authorized  by  legislation 
enacted  after  such  date." 

•US  Air  Force,  Office  of  the  Comptroller. 


Although  this  provision  of  the  law  dealt  only  with 
aircraft,  missile  and  ship  procurement,  the  Congress 
soon  realized  the  desirability  of  expanding  the  re- 
quirement to  other  portions  of  the  DOD  budget. 
Consequently,  there  have  been  seven  additional 
amendments  to  public  law.  A specific  requirement 
now  is  that  research,  development,  test  and  evalua- 
tion (RDT&E);  tracked  vehicles,  personnel 
strengths;  and  other  weapons  procurement  (rifle, 
artillery,  small  arms,  and  torpedoes);  be  subjected  to 
the  annual  authorization  process  prior  to  appropria- 
tion. (Williams,  pp  103-105). 

POSTURE  HEARINGS 

How,  within  this  two-step  framework  of  autho- 
rization and  appropriation  does  the  Congress  meet 
its  Constitutional  obligation?  The  process  begins  in 
January  of  each  year  when  the  Congress  begins  its 
regular  session.  Before  the  detailed  review  of  indi- 
vidual programs,  the  Armed  Services  Committee  of 
both  the  House  and  Senate  hold  military  posture 
hearings.  The  posture  hearings  usually  cover  only 
broad  aspects  of  the  military  budget  including  force 
structure  and  overall  weapon  and  personnel  strength 
levels.  Witnesses  usually  are  service  officials,  includ- 
ing the  Secretary  of  Defense  and  other  top  OSD 
representatives,  the  Service  Secretaries  and  the  mili- 
tary chiefs. 

AUTHORIZATION 

Posture  hearings  are  followed  by  the  authoriza- 
tion hearings.  The  recent  practice  of  the  respective 
Armed  Services  Committees  has  been  to  hold  sepa- 
rate hearings  on  procurement  and  Research,  Devel- 
opment, Test  and  Evaluation  (RDT&E).  Although 
the  principal  witnesses  at  these  hearings  are  nor- 
mally Assistant  Secretaries  of  the  military  depart- 
ments and  the  military  Deputy  Chiefs  of  Staff,  it  is 
not  unusual  for  a program  manager  to  be  called  to 
testify,  especially  for  designated  major  weapon  sys- 
tems. The  primary  responsibility  of  the  witnesses  is 
to  defend  and  support  specific  programs  outlined 
and  the  funds  requested  in  the  President's  budget 
that  are  being  considered  by  the  Committees. 

Because  of  the  shortage  of  time  as  well  as  the 
desire  for  independent  analysis,  authorization  hear- 
ings are  held  simultaneously  in  the  House  and  Sen- 
ate. However,  because  of  the  statutory  requirement 
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those  Armed  Services  and  Appropriations  Commit- 
tee staffers  who  have  provided  a biography  to  the 
Congressional  Staff  Directory  shows  that  the  major- 
ity have  at  one  time  served  on  active  duty  with  one  of 
the  military  services.  Some  are  retired  military  offi- 
cers and  at  least  one  is  currently  a member  of  the  US 
Naval  Reserve.  Others  have  served  on  the  civilian 
side  of  the  Department  of  Defense  including  one 
who  served  for  7 years  as  a Deputy  Director  of 
Legislative  Liaison.  (Brownson,'  p 585ffj. 

Budget  experience  in  the  Executive  Branch  is  a 
highly  desired  qualification  for  staff  members  of  the 
House  Appropriations  Committee. 


PART  III 

STAFF  ROLES  AND  INFLUENCE 


INDIVIDUAL  RESPONSIBILITIES 

Staff  members  interviewed  acknowledge  that  it  is 
difficult  to  define  their  duties  rigorously,  however 
the  performance  of  certain  recurring  tasks  is  ex- 
pected of  the  staffer.  The  role  of  the  House  Appro- 
priations Committee  staffer,  as  described  by 
Fenno " , is  typical  of  that  of  most  committee  staffers: 

“...For  his  subcommittee,  each  clerk  is  expected  to 
schedule  and  oversee  the  routine  of  the  hearings, 
suggest  areas  of  inquiry  for  the  hearing,  make  up 
specific  questions  for  use  in  the  hearings,  prepare 
the  transcript  for  publication,  help  prepare  for  the 
mark  up  session,  oversee  the  routine  of  the  mark 
up,  help  write  the  subcommittee  report,  and  the 
subcommittee  bill,  participate  in  full  Committee, 
sit  with  and  advise  subcommittee  members  during 
floor  debates,  help  schedule  and  prepare  for  con- 
ference committee  meetings,  prepare  materials  for 
use  by  House  conferees,  participate  in  conference 
proceedings,  receive  and  digest  reports  from  the 
investigation  staff,  keep  in  constant  communica- 
tion. in  season  and  out.  with  agency  officials,  and 
accompany  committee  members  when  they  travel 
to  visit  agency  installations.  His  role  requires  that 


he  process  all  the  committee’s  working  documents 
and  that  he  be  present  physically  at  every  stage  of 
decision-making.  “There  may  be  some  part  of  the 
process  that  I miss  or  don’t  know  about,"  said  one 
staff  man,  “but  1 doubt  it."  (Fenno,"  p 182). 

These  responsibilities  are  inherent  in  behind-the- 
scenes  activities  that  might  be  expected  of  a commit- 
tee staffer.  The  role  is  important  and  certainly  one 
that  ensures  the  success  of  the  legislative  process. 


HEARING  PARTICIPATION 

The  staffer  also  plays  another,  more  visible,  role 
that  is  not  cited  by  Fenno.  This  is  the  role  of 
questioner,  along  with  the  committee  members,  dur- 
ing hearings.  This  role  appears  to  be  more  prevalent 
in  the  Armed  Services  Committees  than  in  the 
Appropriations  Committees.  For  example,  a review 
of  the  published  hearings  on  FY  77  authorization 
bill  shows  that  almost  half  of  the  questions  asked  of 
the  Office  of  the  Secretary  of  Defense  and  service 
witnesses  were  asked  by  committee  staffers. 

Where  the  technology  is  advanced  and  the  com- 
mittee staff  is  competent,  frequently  the  committee 
members  assign  to  the  staff  the  actual  questioning  of 
witness.  The  recent  addition  of  two  technically  com- 
petent staff  members  to  the  House  Armed  Services 
Committee  has  permitted  that  committee  to  spend  a 
greater  portion  of  its  hearing  activity  delving  into 
technical  issues. 


STAFF  INFLUENCE 

The  activities  of  the  committee  staff,  as  previously 
discussed,  strongly  suggests  that  the  staffers  have  an 
inherent  potential  to  influence  congressional  deci- 
sions on  weapon  systems  acquisition.  The  exercise  of 
influence  varies,  and,  for  a number  of  reasons.  Pat- 
terson notes: 

“...Staff  influence  varies  among  congressional 
committees  as  a result  of  differences  in  staff  avail- 
ability and  competence,  committee  workload,  and 
structural  factors  in  committee  organization.  At 
the  same  time,  the  potential  influence  of  commit- 
tee staffs  is  considerable  indeed.”  (Patterson,"  p 
411). 


In  the  areas  of  committee  workload  and  commit- 
tee structure,  staff  influence  is  very  much  dependent 
on  the  personality  and  style  of  the  committee  chair- 
man. Fenno,  in  his  paper  on  the  distribution  of 
influence  in  the  House  of  Representatives,  states: 

“...Staff  influence  varies  with  the  confidence 
which  committee  and  subcommittee  members, 
and  especially  their  respective  chairmen,  place  in 
staff  abilities  and  staff  judgment.  Where  the  desire 
to  use  a staff  and  confidence  exist,  staff  members 
constitute  a linchpin  to  internal  committee 
decision-making.  When  these  conditions  are  not 
present,  it  does  not  make  much  difference  what 
kind  of  staff  a committee  has.  Such  staff  influence 
as  does  exist  in  the  House  exists  here — in  the 
committees.”  (Truman,  ' p 66). 

Similarly,  Huitt  comments  regarding  Senate  staff: 

“...first  rate  professionals  do  more  than  carry  out 
assignments.  In  the  offices  of  individual  senators 
they  learn  to  think  like  the  boss;  they  determine  to 
some  degree  who  sees  him  and  what  importunities 
reach  him.  In  the  committee  rooms  they  identify 
the  problems  and  provide  the  facts  and  questions. 
The  product  of  the  Senate  is  to  some  unmeasured 
and  perhaps  immeasurable  degree  their  product. 
Their  influence  probably  would  be  very  easy  to 
overstate,  but  it  does  exist...”  (Truman,1  p 113). 

The  growing  size  of  the  DOD  budget  and  the  in- 
creasing complexity  of  modern  technology  makes  it 
more  and  more  difficult  for  the  individual  congress- 
man or  senator  to  digest  all  information  available. 
Rieselback  observes, 

“...The  more  complex  the  issues,  the  greater  the 
need  of  the  lawmakers  for  technical  expertise  and 
the  greater  the  opportunity  for  the  staff  to  press  its 
own  views."  (Rieselback,"  p 79). 

A number  of  committee  staff  members  have  can- 
didly commented  on  their  ability  to  influence  the 
legislative  process: 

“...I  like  being  close  to  the  levers  of  power  (said 
one  staffer  on  a committee  unrelated  to  DOD). 
My  ideas  have  influence  only  to  the  extent  that  I 
can  persuade  the  Senators  that  they  are  in  the 
public  interest.  The  staff  man  can  have  a lot  of 
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influence  in  these  terms.  If  you  know  you  can’t 
persuade  a member  to  your  own  policy  position, 
you  lay  out  the  alternatives,  and  you've  got  to  be 
as  objective  as  you  possibly  can.”  (Patterson,"  p 
411). 

Regardless  of  how  staff  influence  is  viewed,  there 
can  be  little  doubt  that  it  exists — both  in  potential 
and  in  daily  exercise.  Nevertheless,  such  exercise  of 
influence  that  does  take  place  does  so  only  to  the 
extent  that  it  is  permitted  by  the  committee  mem- 
bers and  especially  by  the  chairman.  The  staff  real- 
izes this  limitation  and  acts  accordingly.  In  his 
contact  with  the  staff,  the  program  manager  must 
assume  that  the  staff  is  acting  for  the  committee  and 
with  its  full  consent. 


INFORMATION,  A SOURCE  OF 
INFLUENCE 

The  amount  of  influence  possessed  by  a given 
staffer  is  measured  to  a great  extent  by  the  intelli- 
gence he  is  able  to  obtain.  Information  is  his  stock  in 
trade. 

What  are  the  information  sources  of  the  staff? 
Much  of  the  information  gathered  by  the  staff  comes 
from  the  DOD  itself  in  various  forms.  The  congres- 
sional inquiry  is  a popular  channel  for  information 
flow.  Such  inquiry  is  treated  by  the  DOD  as  a formal 
request  for  information  and  each  request  is  treated 
with  the  same  degree  of  importance,  whether  it 
comes  from  a Congressman  needing  information  for 
either  his  own  education  or  to  reply  to  a constituent, 
or  whether  it  comes  from  a committee  staffer.  In- 
quiries are  normally  handled  through  legislative 
liaison  offices  which  have  been  established  in  the 
Pentagon  by  DOD  and  each  of  the  military  services. 
In  addition,  each  service  maintains  a small  detach- 
ment of  liaison  personnel  located  in  the  office  build- 
ings of  both  the  House  and  the  Senate.  When  a 
request  for  information  is  received  (usually  by 
telephone),  it  is  relayed  to  the  office  having  primary 
responsibility. 

Usually  the  request  is  for  written  material — a 
position  paper  or  a fact  sheet.  Occasionally,  a brief- 
ing is  requested  and  it  will  be  conducted  in  the  office 
of  the  staff  member.  This  may  involve  having  the 
program  manager  travel  to  Washington  for  the 
briefing. 
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An  additional  source  of  important  program  infor- 
mation is  the  justification  material  submitted  to 
Congress  with  the  President’s  annual  budget.  This 
justification  material  is  in  the  form  of  several  vol- 
umes that  contain  thousands  of  pages  of  detailed 
program  data.  The  data  includes  funding  require- 
ments, schedules,  purchase  quantities,  technical  per- 
formance parameters,  and  narrative  discussions  of 
requirements  and  planned  activities.  Detailed  for- 
mats and  instructions  for  this  material  are  contained 
in  the  DOD  Budget  Guidance  Manual DOD 
71 10-1-M,  published  by  the  Office  of  the  Assistant 
Secretary  of  Defense  (Comptroller).  The  manual  is 
revised  periodically  to  reflect  additional  or  changed 
requirements  of  the  respective  congressional 
committees. 

Witness  statements  and  hearing  transcripts  also 
serve  as  information  to  committee  staffers.  Witness 
statements  are  required  to  be  submitted  several  days 
in  advance  of  hearings  so  that  they  may  be  analyzed 
by  the  staff  for  issues  to  be  raised  during  the  hear- 
ings. Statements  of  service  witnesses  are  reviewed 
and  compared  with  previously  received  DOD  policy 
statements.  A comparison  is  made  of  the  current 
position  of  witnesses  with  positions  taken  by  the 
same  witnesses  in  previous  hearings.  And  finally,  the 
statements  are  compared  with  other  information 
gathered  by  the  staff.  Similarly,  transcripts  of  hear- 
ings before  other  committees  are  reviewed. 

Committee  staffers  occasionally  take  a request  for 
information  directly  to  the  program  manager.  Cer- 
tain staff  members,  for  example,  make  annual  trips 
to  military  installations  for  the  purpose  of  gaining 
first  hand  information  on  major  acquisition  pro- 
grams. In  the  course  of  these  visits,  the  staff  mem- 
bers expect  to  be  briefed  on  program  status,  problem 
areas,  and  anticipated  funding  needs.  Field  trips  are 
taken  to  contractors'  plants  where  staff  members 
receive  program  briefings,  talk  to  engineers  and 
technicians,  see  and  touch  the  hardware,  and  wit- 
ness tests  and  demonstrations. 

Contractors  recognize  the  potential  benefits  of 
such  visits  and  actively  court  individual  staff  mem- 
bers. The  preference  of  lobbyists  for  the  attention  of 
the  staff  instead  of  that  of  committee  members  is 
summed  by  one  business  representative  who  noted. 
“The  members  are  busy.  They  usually  don't  have  the 
time  to  listen  to  a sales  pitch  And  often  it's  the  staff 
that  really  matters  anyway."  (US  News  and  World 
Report,  p 26) 


Other  outside  sources  of  information  include  the 
research  services  of  the  Library  of  Congress,  reports 
of  the  Government  Accounting  Office,  technical 
journals  and  trade  magazines,  newspaper  stories, 
liaison  with  other  committee  staffs,  and  information 
from  such  private  organizations  as  the  Brookings 
Institute.  In  fact,  the  wide  availability  of  informa- 
tion to  committeestaffshashrought  about  increasing 
suggestions  that  staffs  be  enlarged  to  handle  all  data. 
(Harris,  pp  117-1 19  and  Truman,'  p 130).  A 
counter  argument  is  that  more  staff  would  only 
create  new,  more  complex  problems  to  compete  for 
the  limited  attention  of  the  congressmen  and  sena- 
tors. At  the  same  time,  there  is  always  the  danger  of 
creating  a legislative  bureaucracy  that  will  dilute 
and  color  the  information  gathered  by  the  staff, 
thereby  in  effect  making  the  committee  a captive  of 
the  staff.  (Rieselback,"  p 384). 

The  fact  that  committee  staffs  do  not  have  access 
to  a wealth  of  data  means  that  they  must  pick  and 
choose  the  data  that  is  passed  on  to  busy  committee 
members.  This  requirement  for  the  staff  to  exercise 
judgment  provides  the  greatest  opportunity  to  influ- 
ence, if  not  actually  make,  the  ultimate  congression- 
al decision  affecting  weapon  system  programs.  Im- 
plications of  this  reality  and  the  effects  on  program 
manager — congressional  staff  relations  are  ad- 
dressed in  upcoming  paragraphs. 


PART  IV 

PROGRAM  MANAGER- 
CONGRESSIONAL  STAFF 
RELATIONS 

Clearly,  the  congressional  staffer  can  be  an  impor- 
tant force  in  determining  the  direction  and  funding 
level  of  a given  weapon  system  program.  Where  the 
staff  is  not  convinced  of  the  value  of  the  program, 
the  chances  are  slim  that  the  program  will  advance 
through  the  congressional  approval  process  without 
a reduction  or  redirection.  Conversely,  a program 
that  makes  sense  to  committee  staff  stands  a good 
chance  of  approval.  It  is  incumbent  on  the  part  of 
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every  program  manager,  when  the  opportunity  ari- 
ses, to  ensure  that  he  communicates  total  program 
understanding  to  the  appropriate  members  of  the 
committee  staff. 

In  the  process  of  budget  formulation,  individual 
program  budgets  may  be  reduced  "inhouse”  by  the 
service  headquarters,  OSD,  the  Office  of  Manage- 
ment and  Budget  (OMB),  or  even  the  President, 
before  the  budget  is  submitted  to  the  Congress.  The 
President's  budget  submission  represents  a balance 
in  priorities  of  total  demands  on  the  nation’s  tax 
dollars.  Therefore,  all  witnesses  appearing  at  con- 
gressional hearings  are  advised  by  OMB  Circular  A- 
10  that: 

• Personal  opinions  will  not  be  volunteered 
which  reflect  positions  inconsistent  with  the 
program  and  appropriation  requests  the  Presi- 
dent has  transmitted  to  the  Congress. 

Witnesses  are  permitted,  to  respond  to  a direct 
request  for  personal  opinion  with  the  appropriate 
caveat: 

• In  expressing  personal  opinions  relating  to 
such  program  and  appropriation  requests  in 
response  to  specific  requests  therefor,  wit- 
nesses will  refer  to  the  extent,  if  any,  and 
should  make  clear  that  the  expression  of  the 
opinion  is  not  a request  for  additional  funds. 

An  attempt  to  lobby  for  additional  funds  with 
committee  staff  outside  formal  hearings  would  only 
create  additional  problems  for  the  program  con- 
cerned, and  the  budget  as  a whole.  Issues  created  by 
an  overzealous  proponent  might  suggest  that  the 
budget  as  submitted  does  not  reflect  actual  require- 
ments. Such  an  indication  could  undermine  the 
credibility  of  the  entire  budget. 

Knowing  the  orientation  and  the  needs  of  com- 
mittee staff  is  the  full  time  responsiblity  of  legislative 
liasion  personnel  in  the  Pentagon,  and  the  program 
manager  should  work  through  these  channels.  Liai- 
son personnel  maintain  contact  with  committee  staff 
on  a daily  basis  and  have  established  strong  relations 
built  on  trust  and  mutual  confidence.  When  infor- 
mation is  sought  by  committee  staff  from  the  pro- 
gram manager,  the  request  is  usually  directed 


through  liaison  personnel.  On  those  occasions  when 
urgency  necessitates  direct  contact  between  a staffer 
and  a program  manager,  liaison  personnel  should  be 
notified  as  soon  as  possible  to  assure  that  appropri- 
ate service  headquarters  and  DOD  personnel  are 
alerted  to  potential  congressional  issues.  Through 
frequent  contact  with  committee  staff,  liaison  per- 
sonnel may  be  able  to  provide  a measure  of  perspec- 
tive as  to  what  may  be  behind  a specific  request  for 
information.  This  reduction  of  uncertainty  offers 
greater  opportunity  for  positive  communication  and 
less  time  is  wasted  on  tangential  issues. 

One  final  comment  is  appropriate.  Contact  with  a 
committee  staffer  sometimes  places  the  program 
manager  in  a defensive  role.  He  may  find  it  neces- 
sary to  justify  his  program  to  an  individual  who  has 
an  opposing  view.  In  such  situations,  especially 
when  the  atmosphere  is  informal,  extra  attention 
must  be  given  to  maintaining  high  professional  stan- 
dards and  to  responding  to  disagreement  in  a rea- 
sonable, factual  manner. 


PART  V 
SUMMARY 


The  professional  staffer  on  those  congressional 
committees  having  oversight  responsiblity  for  mili- 
tary weapon  system  acquisition  is  a key  element  in 
the  budget  approval  process.  Staffs  are  increasing  in 
technical  competence  and  growing  in  size.  The  in- 
creased competence  and  numbers  means  that  proba- 
bly they  are  going  to  exhibit  more  and  more  interest 
in  technical  and  management  decisions  made  by 
program  managers. 

The  technical  competence  of  committee  staff  com- 
bined with  their  knowledge  of  program  information 
provides  a unique  opportunity  to  influence  the  bud- 
get decisions  made  by  the  Congress  Every  program 
manager  must  recognize  this  influence  Each  pro- 
gram manager  should  work  to  earn  the  confidence 
and  commitment  of  committee  staffers  just  as  he 
would  work  to  earn  the  confidence  of  any  military 
staff  officer  or  other  decision  shaper. 
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What’s  Happened  To  The  Basics? 

By  WILLIAM  W.  THYBONY 


"Important  principles  may  and  must  be  inflexible.  ” 

— Abraham  Lincoln 


The  material  presented  here  consists  of  excerpts  from  an  article  that  first  appeared 
in  Vol  9,  Issue  1,  of  the  National  Contract  Management  Journal.  The  author 
graciously  revised  these  excerpts  to  update  the  information.  To  preserve  the 
relation  with  the  previous  article  and  to  assist  the  reader  seeking  to  correlate  all  of 
the  material,  routine  Review  editorial  changes  were  not  made  to  this  copy  The 
references  and  footnotes  follow  the  format  of  the  original  article  and  not  the 
Defense  Systems  Management  Review  format. 

Editor's  note. 


i 
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During  an  era  when  procurement  officials,  professionals,  and  technicians,  both  in  Government  and 
industry,  are  deeply  and  almost  totally  absorbed  with  complex  problems  and  exotic  (and  often  confusing) 
policy  and  procedural  requirements,  it  is  rare  to  focus  the  spotlight  on  the  basics  of  Federal  procurement 
Often  they  are  only  backstage  scenery.  Today's  paper  implosion  on  the  individual  makes  it  next  to 
impossible  to  sit  back  and  relate  the  solutions  of  daily  problems  to  the  bedrock  of  procurement  doctrine. 
And  yet  it  is  a discipline  that  needs  cultivation. 

The  magnitude,  complexity,  and  diversity  of  Government  procurement  involves  a huge  cooperative 
effort  and  requires  a high  degree  of  understanding  and  education.  Its  impact  on  the  level  and  trend  of 
over-all  economic  activity  in  the  United  States  is  considerable,  and  Federal  procurement  programs  affect 
almost  all  business  firms  directly  or  indirectly.  The  Government  as  a customer  is  engaged  in  millions  of 
procurement  actions  each  year,  utilizing  public  funds  w hich  comprise  a great  share  of  the  tax  dollar  The 
great  size  of  such  an  undertaking  in  itself  solidifies  the  need  to  examine  the  basics. 

The  procurement  process  is  beset  with  a good  number  of  problems  that  could  have  been  avoided  The 
seriousness  of  many  would  have  been  less,  if  at  the  outset  good  judgment  and  foresight  based  on  the 
fundamentals  of  Government  contracting  had  been  used.  Often,  those  in  the  Government  procurement 
business,  whether  on  the  buyer  or  seller  side,  become  so  specialized  that  after  time  goes  by  they  lose  sight 
of  the  fundamentals.  Knowledge  of  the  basics  and  application  on  a day-by-day  basis  is  essential.  It  is 
elementary  not  only  to  the  novice,  but  to  professionals  of  long  standing  experience  as  w ell,  to  be  on  solid 
ground. 

I.iisl  public  address.  April  I S . I u f, s 
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Current  dialogue  and  debate  is  drawn  to  the  prevailing  sophisticated  modes  of:  cost  accounting 
standards,  major  systems  acquisition,  research  and  development  contracting,  management  systems, 
parametric  cost  estimating,  pie  cost,  independent  research  and  development,  return  on  investment, 
design-to-cost,  independent  research  and  development,  return  on  investment,  design-to-cost,  "should 
cost,”  cost  sharing,  technical  transfusion,  appeals,  claims,  defective  pricing,  industrial  funding,  patent 
policy,  rights  in  technical  data,  consequential  damages,  economic  price  adjustments,  etc.,  etc.  Granted, 
all  are  important  — and  yet  many  of  today’s  issues  could  be  simpler  and  procurements  made  sounder  if 
they  rested  on  a firm  foundation  of  the  basics. 

The  Legacy  of  Procurement  Law 

To  set  the  prime  tone  it  is  significant  to  know  that  the  hard  core  basics  have  derived  from  an 
evolutionary  legislative  process. 

From  the  beginning  Federal  procurement  has  been  guided  by  the  need  to  acquire  goods  and  services  of 
specified  quality  on  a timely  basis  by  maximizing  competition  and  obtaining  reasonable  prices,  with  the 
assurance  that  Government  officials  are  publicly  accountable  for  their  actions. 

The  legacy  of  procurement  law  inherited  by  procurement  officials  of  today  has  been  unfolding  since  the 
founding  of  the  nation.  It  represents  the  culmination  of  the  efforts  and  contributions,  through  war  and 
peace,  of  the  courts.  Congressmen,  Government  officials,  buyers,  lawyers,  accountants,  military  leaders, 
civil  servants,  industry  executives,  and  the  general  public. 

Looking  into  the  past  we  see  a long  and  complex  historical  evolution  of  procurement  law,  beginning  in 
1792  when  the  Department  of  Treasury  was  given  responsiblity  for  purchasing  and  contracting.  This 
evolution  continues  to  this  day,  and  the  complexity  intensifies  at  a rapid  rate.  Still,  despite  the  vast  legal, 
legislative  and  procedural  background  of  the  procurement  function,  the  meaning  of  the  term  never  has 
been  precisely  fixed. 

What  Is  Procurement? 

What  is  procurement'’  In  the  procurement  community  the  answer  would  seem  so  obvious  that  it  should 
be  unnecessary  to  address.  But  oddly  there  is  a wide  disparity  of  opinion.  No  two  people  will  give  the 
same  answer.  There  is  no  common  definition  in  the  procurement  regulations.  The  Armed  Services 
Procurement  Regulation  (ASPR)  and  the  Federal  Procurement  Regulations  (FPR)  differ. 24  The  primary- 
procurement  laws  contain  no  definition  of  "procurement,”  nor  does  the  Office  of  Federal  Procurement 
Act.” 

Consequently,  since  a summation  on  procurement  basics  calls  for  such  a definition,  for  the  purpose  of 
this  paper  "procurement"  means  the  act  or  process  of  obtaining  or  acquiring  property  or  services  to  meet 
a public  need  by  the  payment  of  money  or  its  equivalent.  In  its  most  acceptable  sense,  it  encompasses 
purchasing,  contracting,  renting,  leasing,  and  bartering.  It  includes  the  functions  of  advance  procure- 
ment planning;  description  (but  not  determination)  of  requirements;  solicitations  for  bids  or  proposals 
(including  the  preparation  and  publicizing  of  solicitations)  based  on  expressed  needs  of  what,  w here  and 
when;  the  submission  of  bids  or  proposals;  evaluation  of  bids  and  proposals;  conduct  of  negotiations; 
selection  of  contractors  and  the  preparation  and  award  of  contracts;  and  the  administration  of  contracts 
to  final  payment  and  completion. 
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What  Are  The  Basics? 

The  basics  of  Federal  procurement  have  grown  and  matured  over  the  years  through  a maze  of  not  only 
varied  legislative,  but  administrative  efforts  as  well,  to  develop  a system  providing  safeguards  against 
graft,  favoritism,  questionable  ethics,  war  profiteering,  collusion,  and  inefficiency,  and  to  protect  the 
integrity  of  the  competitive  and  public  bidding  system  once  established. 

What  then  are  the  real  basics?  Here  again  there  will  not  be  full  agreement.  Why?  Because  they  are  not 
compiled  in  any  one  law  or  regulation,  and  opinions  of  individuals  will  vary  depending  on  their 
specialization,  knowledge,  and  the  divergent  missions  of  their  organizations. 

However,  in  spite  of  this  and  from  a broad  and  objective  perspective,  the  condensation  set  forth  below 
is  offered  as  representative  of  the  basics  of  Federal  procurement.  There  can't  be  any  quarrel  with  the 
statements  included  — there  may  be  dispute  as  to  whether  the  list  is  all-inclusive.  Miss  any  one  of  the 
following  and  you’re  in  trouble: 

1.  The  power  of  the  United  States  to  contract  is  based  on  the  general  and  implied  powers  contained  in 
the  Constitution  of  the  United  States. 

2.  The  President  of  the  United  States,  as  the  Nation’s  Chief  Executive  Officer,  is  resp  nsible  for 
Government  purchasing  functions. 

3.  The  Administrator  for  Federal  Procurement  Policy  (head  of  the  Office  of  Federal  Procurement 
Policy  in  the  Office  of  Management  and  Budget)  by  law  provides  overall  direction  of  Government 
procurement  policy.” 

4.  Upon  entering  a contract  the  Government  becomes  subject  to  the  rule  of  Federal  law  as  a private 
individual.” 

5.  The  U.S.  Government  as  a contractor  is  not  liable  for  its  soverign  acts." 

6.  No  contract  or  purchase  on  behalf  of  the  United  States  can  be  made  unless  it  is  authorized  by  law  or 
is  under  an  appropriation  adequate  to  its  fulfillment.  A contract  liability  expires  when  the  appropriation 
is  exhausted.” 

7.  Expenditures  or  contract  obligations  in  excess  of  funds  appropriated  are  prohibited.  (Anti- 
Deficiency  Act)." 

8.  Federal  agencies  may  make  use  of  funds  only  for  the  purpose  appropriated,  in  the  absence  of  specific 
authority  for  another  purpose." 

9.  No  contractor  can  be  required  to  perform  a Government  contract  in  a manner  prohibited  by  law  or 
in  response  to  coercion  or  promised  reward  by  a Government  official  or  employee. 

10.  No  official  or  employee  of  the  Government  may  giveaway  any  vested  right  of  the  Government. 

11.  The  Government  contracting  officer  is  ihe  agent  of  the  Government  under  any  Government 
contract.  His  authority  is  limited.  A Government  contracting  officer  may  bind  the  Government  only  to 
the  extent  of  his  actual  authority,  whether  it  be  expres  et,  or  implied  Authority  may  be  implied  from  a 
duty  imposed  upon  the  Government  agent  or  from  someexpi  css  authority  given  to  him 

"P.  L.  <>3-400;  August  30. 1974.  8R  Stat  766 

"US  v Allegheny  County.  332  US  174  ( 1 1,44 1 and  in  Re  American  Boiler  Hi  vi  v 220  I 2d  3 1 4 ( I4XX) 

" 'Jones  i.  United  States.  1 Cl.  Cl  383,  383  ( I UPS) 

' 42  U.S.C.  1 1.  Shipman  i l hired  States.  1 8 Ct  Cl  1 18 1 1883).  37  Comp  Gen  W'-U  1 *■ " ) 

”31  U.S  C 665(a),  ("Anti  Deficiency  Act") 

”28 Comp.  Gen  38(1048) 
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12.  The  risk  of  dealing  with  a Government  agent  not  authorized  to  act  like  a private  contractor,  when  a 
Government  agent  does  not  have  actual  authority  to  act.  the  Government  is  not  bound  by  his  acts. 


The  Supreme  Court  has  said: 

i 

i Although  a private  agent,  acting  in  violation  of  specific  instructions,  yet  within  the  scope  of  his  general 

authority,  may  bind  his  principal,  the  rule  as  to  the  effect  of  the  like  act  of  a public  agent  is  otherwise, 
for  the  reason  that  it  is  better  that  an  individual  should  occasionally  suffer  from  the  mistakes  of  public 

I officers  or  agents,  than  to  adopt  a rule  which,  through  improper  combinations  or  collusion,  might  be 

turned  to  the  detriment  and  injury  of  the  public. “ 

13.  The  Government  is  required  to  acquire  goods,  services,  and  facilities  of  the  requisite  quality  and 
within  the  time  needed  at  the  lowest  reasonable  cost,  utilizing  competitive  procurement  methods  to  the 
maximum  extent  practicable.'’’’ 

14.  The  Government  relies  upon  the  private  enterprise  system  to  supply  its  needs,  except  where  it  is  in 
the  national  interest  for  the  Government  to  provide  directly  the  product  or  services  it  uses." 

15.  The  two  principal  methods  of  procurement  and  forming  of  contracts  are  formal  advertising  and 
negotiation.  Formal  advertising  is  the  preferred  method,  unless  it  is  not  feasible  or  practicable  and  one  of 
the  statutory  exceptions  to  formal  advertising  is  applicable  — then  the  procurement  may  be  negotiated." 
The  Commission  on  Government  Procurement  concluded  that  statutory  changes  should  be  made  which 
would  require  formal  advertising  when  conditions  justify  its  use,  but  that  negotiated  procurement  should 
be  authorized  and  recognized  as  an  acceptable  and  normal  alternative  to  formal  advertising."  S.  2309. 
j introduced  by  Senator  Percy  in  the  94th  Congress  would  have  implemented  the  Commission’s 

! recommendations  in  this  respect  by  authorizing  the  following  methods  of  procurement:  small  purchase 

procedures,  formal  advertising,  competitive  negotiation,  and  noncompetitive  negotiation.  S.3005.  intro- 
duced by  Senator  Chiles,  also  in  the  94th  Congress,  contained  the  same  provisions,  except  noncompeti- 
tive negotiation  would  have  been  considered  an  exception  rather  than  an  authorized  method  of 
procurement.  Similar  recommendations  have  been  made  in  the  past.  Notable  among  them  are  recommen- 
dations contained  in  the  National  Security  Industrial  (NSIA)  Defense  Acquisition  study"  and  in  an 
article  by  Robert  B.  Hall.  U.S.  General  Accounting  Office. ’* 

16.  Known  qualified  suppliers  are  given  an  equal  chance  to  compete 

17.  In  negotiated  procurements,  written  or  oral  discussions  are  conducted  with  responsible  offerors 
within  a competitive  range,  price  and  other  factors  considered. 

18.  Contract  awards  are  made  only  to  firms  submitting  bids  or  offers  which  are  the  most  advantageous 
to  the  Government,  price  and  other  factors  considered. 

19.  Contracts  are  not  awarded  unless  the  price  is  deemed  to  be  reasonable. 

20.  Normally,  reasonableness  of  price  is  based  on  adequate  price  competition  (forces  of  competition  in 
the  market  place)  and  is  determined  by  price  analysis. 


'Volume  I,  Report  of  the  Commission  on  Government  Pn*curement.  December  31,  1972 
Whiteside  » l ’ntted  States.  93  l ’ S 247,2V  ( 1876.  U.S  Supreme  Court 
"P.  L.  93-400;  August  30.  1974.  88  Stat  796 

'Office  of  Management  Budget  (OMB)  Circular  No  A-76.  August  30.  1967 
"10  U S C 2304.41  U S C 253 

Recommendation  32.  National  Security  Industrial  Association  Defense  Acquisition  Study.  July  1970 

‘ The  A rmeil  Services  Prt\n  remen  t Act  ot 7 W Should  He  Reformed.  Robert  B Hall.  L’  S General  Accounting  Office.  National 
Contract  Management  Journal.  Vol  3.  No.  I.  Spring  1969 
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21.  Generally,  in  negotiated  procurements  where  price  has  not  been  based  on  the  competitive  forces  of 
the  market  place,  offerors  are  required  to  submit  cost  or  pricing  data  to  assure  reasonableness  of  price  or 
cost  estimates  and  to  form  a basis  for  cost  analysis.  (The  "Truth  in  Negotiations  Act"“,  briefly  stated, 
requires  that  prior  to  the  awards  of  noncompetitive  contracts  and  all  contract  modifications  exceeding 
$100,000,  prime  contractors  and  subcontractors  will  have  to  submit  to  the  buyer  cost  or  pricing  data 
certified  as  to  its  accuracy,  completeness  and  currency.  It  allows  the  Government  to  reduce  the  contract 
price  of  the  prime  contract  if  it  is  later  determined  that  the  data  submitted  as  of  the  date  of  the  price 
agreement  were  not  accurate,  complete  and  current  [defective  data].  Only  downward  adjustments  of 
price  are  considered.) 

22.  Contracts  are  priced  separately  and  independently,  and  no  consideration  is  given  to  losses  or  profits 
realized  or  anticipated  in  the  performance  of  other  contracts. 

23.  Contracts  are  awarded  only  to  those  who  are  responsive  to  the  Government's  requirements  and  are 
technically  and  financially  able  to  perform. 

24.  Government  contracts  promote  equal  employment  opportunities  for  all  persons,  regardless  of  race, 
color,  religion,  sex,  or  national  origin. 

25.  Government  contracting  promotes  small  business,  including  minority  business  enterprises. " 

26.  US.  domestic  source  products  are  preferred  over  foreign  products.  '*' 

27.  Fair  dealing  and  equitable  relationships  are  fostered  between  the  parties." 

28.  Items  supplied  by  a contractor  are  inspected  and  accepted  by  the  Government  before  payment  of 
invoices. 

29.  Legal  and  administrative  remedies  are  designed  to  provide  for  fair  and  equitable  treatment  of  the 
contracting  parties. 

The  basics  such  as  those  in  the  above  digest  should  be  officially  determined  and  published  in  the  Armed 
Services  Procurement  Regulation  and  the  Federal  Procurement  Regulations,  and  thereafter  all  content  of 
these  regulations  should  be  tested  aginst  and  be  consistent  with  the  basic  policy  statements  and  principles. 
Donald  N.  Pitts,  TRW,  writing  in  a News  Letter  of  the  National  Contract  Management  Association 
stated:  ”1  urge  all  in  the  Government  contracting  community  to  promote  the  concept  and  to  apply  their 
professional  experience  to  the  development  of  a set  of  Federal  Procurement  Principles,  which  ultimately 
must  be  established.  Only  by  establishing  and  building  up  from  a solid  foundation  can  we  ever  hope  to 
achieve  greater  efficiency  in  the  expenditure  of  public  funds  in  Government  procurement"' 

What  Is  A Contract? 

A contract  is  the  prime  instrument  used  by  the  Government  to  obtain  supplies  and  services  from 
private  business  firms  and  other  organizations.  Generally,  the  law  that  determines  the  essential  validity  of 
Government  contracts  is  similar  to  that  w hich  governs  private  contracts. 

In  this  sense,  a contract  is  an  agreement  which  creates  an  obligation.  Its  essentials  are  competent 
parties,  subject  matter,  a legal  consideration,  mutuality  of  agreement,  and  mutuality  of  obligation.'*  In  its 
simplest  form  it  is  nothing  more  than  a system  of  legally  enforceable  rights  and  obligations 


Appendix  G.  Commission  on  Government  Procurement  Report,  December  31.  1972 
I5CSC  631  64?  (Small  Business  Act  of  1953.  as  amended) 

’41  I SC  10(a)-  (d)(Hu>  American  Act) 

"P  L 93-400.  August  30.  1974,  88  Stat  796 

Ifore  CiWimcnts  hcdcnil  Pn\urenient  Principles.  Donald  N Pitts.  TRW.  National  Contract  Management  Association  News 
I etter.  March  1972 

*1 7 Corpus  Juris  Secundum.  Contracts  la 
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Contracts  require  the  essential  elements  of  offer  and  acceptance.  These  elements  constitute  the  means 
by  which  a contract  is  consummated  and  the  absence  of  either  element  prevents  the  formation  of  a 
contract.  In  Government  procurements,  the  invitation  for  bids,  request  for  quotations  or  proposals 
constitutes  a request  by  the  Government  for  offers  of  a certain  nature.  The  bid  or  proposal  submitted  by 
the  party  solicited  is  in  fact  the  offer  and  the  subsequent  contract  award  constitutes  acceptance."1  An  offer 
cannot  be  revoked  after  its  acceptance  without  the  acceptor’s  consent;  but  it  may  be  revoked  at  any  time 
before  acceptance,  even  though  it  allows  a specified  time  for  acceptance,  unless  it  is  under  seal  or 
supported  by  a consideration.4"  While  under  ordinary  principles  an  offeror  may  withdraw  or  modify  his 
offer  at  any  time  prior  to  acceptance,  a distinction  has  been  drawn  when  an  offer  in  the  form  of  a bid  is 
made  to  the  Government.  In  that  situation,  where  there  is  no  mistake,  or  unreasonable  delay,  the  offer 
may  be  withdrawn  or  modified  as  a matter  of  right  only  until  the  date  and  h r set  for  opening  of  bids. 
Subsequent  to  bid  opening,  the  Government  has  the  power  to  award  a contract,  on  the  basis  of  the  offer 
submitted,  for  a specified  period  of  time.” 

Most  commercial  relationships  expressed  in  contracts  are  relatively  simple  compared  to  the  usual 
Government  contracts,  which  are  normally  complex,  lengthy  documents  whose  award  and  performance 
are  controlled  by  equally  complex  statutes  and  regulations.  Also,  there  are  essential  differences  in 
Government  contracts,  as  compared  to  commercial  agreements,  which  make  them  unique. 

For  instance,  the  Government  may  change  its  mind  and  unilaterally  terminate  a contract  for  its  own 
convenience;  it  may  issue  changes  in  delivery  points,  method  of  shipment,  and  specifications  during 
performance  without  the  contractor’s  consent;  and  if  the  company  has  a dispute  w ith  the  Government 
contracting  officer,  the  decision  may  be  appealed,  but  it  is  resolved  by  one  party  to  the  contract  — the 
Government,  through  its  Boards  of  Contract  Appeals.  And  an  apparent  contract  is  not  a contract  if  the 
contracting  officer  acted  beyond  his  authority,  even  though  the  contractor  relied  to  his  detriment  upon 
unauthorized  representations.  The  courts  have  reasoned  that  the  risk  of  doing  business  with  an 
authorized  contracting  officer  should,  as  a matter  of  policy,  fall  on  the  individual  contractor  rather  than 
the  genera)  public. 


In  brief,  the  prerequisites  for  the  formation  of  a Government  contract  are;  ( 1 ) any  formal  execution  as 
required  by  statute  or  regulation;  (2)  a specific  appropriation  adequate  to  the  contract  or  general 
contractual  authorization;  (3)  the  agent  of  Government  has  actual  authority  or  his  act  is  ratified  by  a 
person  with  authority;  and  (4)  the  resultant  contract  is  not  prohibited  by  some  statute  or  regulation 
pursuant  to  a statute. ” 

The  primary  procurement  regulations  differ  somewhat  in  their  definitions  of  a contract. 

The  Federal  Procurement  Regulations  state  that  "contract”  means  establishment  of  a binding  legal 
relation  basically  obligating  the  seller  to  furnish  personal  property  or  or  nonpersonal  services  (including 
construction)  and  the  buyer  to  pay  therefor.  It  includes  all  types  of  commitments  which  obligate  the 
Government  to  an  expenditure  of  funds  and  which,  except  as  otherwise  authorized,  are  in  writing.  In 
addition  to  a two-signature  document,  it  includes  all  transactions  resulting  from  acceptance  of  offers  by 
awards  or  notices  of  awards;  agreements  and  job  orders  or  task  letters  issued  thereunder;  letter  contracts: 
letters  of  intent;  and  orders,  such  as  purchase  orders,  under  which  the  contract  becomes  effective  by 
written  acceptance  or  performance.  It  also  includes  contract  modifications.41 


J 

The  Armed  Services  Procurement  Regulation  defines  "contracts”  as  meaning  all  types  of  agreements  ^ 
and  orders  for  the  procurement  of  supplies  or  services.  It  includes  awards  and  notices  of  award;  contracts 
of  a fixed-price,  cost,  cost-plus-a-fixed-fee,  or  incentive  type;  contracts  providing  for  the  issuance  of  job 
orders,  task  orders,  or  task  letters  thereunder;  letter  contracts,  and  purchase  orders.  It  also  includes 
supplemental  agreements  with  respect  to  any  of  the  foregoing. 

A wide  variety  of  types  of  contracts  are  authorized  for  Government  contracting. “ They  are  normally 
; classified  according  to  compensation  for  cost  of  performance  and  the  amount  and  type  of  profit  incentive 

offered  the  contractor  to  meet  or  exceed  specified  targets. 

Selection  of  contract  type  is  determined  by  such  factors  as  the  financial  liability  of  the  Government,  the 
adequacy  of  cost  information  furnished  by  the  contractor,  the  nature  of  the  work,  associated  risks,  and 
current  market  conditions. 

Many  serious  problems  would  be  prevented  if  the  contractor  was  completely  familiar  with  all  of  the 
provisions  in  his  Government  contract.  It  is  imperative  that  he  know  precisely  what  is  required  of  him;  he 
should  know  his  rights  and  responsibilities. 

Too  frequently  a Government  contractor  has  learned  too  late  that  prescribed  contract  “boilerplate," 
although  a formality,  means  what  it  says,  and  that  its  stringent  provisions  may  be  invoked  against  him.  It 
is  basic  to  know  that  the  Government  is  not  allowed  to  have  a heart  in  administering  contracts.  A 
contractor  must  produce  strictly  in  accordance  with  the  specifications  of  his  agreement  with  the 
Government  and  within  the  delivery  time  specified,  or  he  may  have  his  contract  terminated  for  default 
with  consequences  that  could  be  disastrous  for  him. 

i 
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What  Are  the  Kthics? 

Corollary  to  the  basics  of  procurement  policy  are  the  basic  standards  of  conduct  relating  to  the 
public/private  interface. 

Businessmen  selling  to  the  Government  and  Government  employees  assume  responsibilities  of  ethical 
conduct  which  are  greater  than  found  in  the  private  commercial  world  In  Government  procurement,  the 
principles  of  honesty,  integrity,  fair  dealings  and  public  confidence  are  requisite.  The  involvement  of 
public  interests  and  the  expenditure  of  public  funds  demand  an  impeccable  standard  of  conduct. 

The  underlying  policy  for  Government  officials  and  employees  is  that:  where  Government  is  based  on 
the  consent  of  the  governed,  every  citizen  is  entitled  to  have  complete  confidence  in  the  integrity  of  his 
Government,  and  each  individual  officer,  employee,  or  adviser  of  Government  must  help  to  earn  and 
must  honor  that  trust  by  his  own  integrity  and  conduct  in  all  official  actions. 

In  consideration  of  the  paramount  importance  for  maintaining  the  highest  possible  standard  of 
excellence  of  human  conduct  in  Government/contractor  relationships,  a large  body  of  laws,  executive 
orders,  regulations,  and  directives  dealing  with  ethical  practices  and  the  conduct  of  individuals  has 
evolved  over  the  years  However,  not  all  of  the  ground  rules  are  in  writing;  some  are  based  on  custom  and 
require  the  use  of  common  sense  and  the  experience  of  sound  judgment. 
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From  the  mass  of  requirements  and  prohibitions,  a pattern  for  guidance  unfolds,  although  it  is 
cautioned  that  pertinent  statutes  and  directives  must  be  known  and  complied  with.  The  following  is  a 
compendium  which  embraces  the  cardinal  principles  of  required  and  acceptable  ethical  practices: 

1.  A Government  employee  should: 

a.  Put  loyalty  to  the  highest  moral  principles  and  to  country  above  loyalty  to  persons,  party,  or 
Government  department. 

b.  Expose  corruption  w henever  discovered. 

c.  Conduct  himself  in  such  manner  that  his  work  is  effectively  accomplished  while  observing  the 
requirements  for  courtesy,  consideration,  and  promptness  in  dealing  with  the  public  and  other 
Government  personnel 

d.  Perform  business  dealings  with  contractors  and  potential  suppliers  in  a manner  above  approach 
in  every  respect,  and  assure  that  his  conduct  is  such  that  he  would  have  no  reticence  in  making  a full 
public  disclosure  of  his  actions. 

e.  Refrain  from  any  private  business  or  professional  activity  which  would  place  him  in  a position 
where  there  is  a conflict  between  his  private  interests  and  the  public  interests  of  the  United  States, 
including  the  avoidance  of  an  appearance  of  such  a conflict. 

f.  Conduct  all  business  with  Government  suppliers  on  an  arm's  length  relationship  basis 

2.  A Government  employee  should  not: 

a.  Solicit  or  accept  directly  or  indirectly,  any  gift,  gratuity,  favor,  entertainment,  loan,  or  any  other 
thing  of  monetary  value,  either  directly  or  indirectly  from  any  individual  or  organization  w hich  has,  or  is 
seeking  to  obtain,  contractual  or  other  business  or  financial  relationships  with  his  agency 

b.  Give  preferential  treatment  or  special  favors  to  anyone,  whether  for  remuneration  or  not 

c.  Lose  complete  independence  or  impartiality  of  action. 

d.  Affect  adversely  the  confidence  of  the  public  in  the  integrity  of  the  Government 

e.  Use  any  information  coming  to  him  confidentially  in  the  performance  of  Governmental  duties  as 
a means  for  making  private  profit. 

f.  Have  a direct  or  indirect  financial  interest  that  conflicts  substantially,  or  appears  to  conflict 
substantially,  with  his  official  duties  and  responsibilities. 

g.  Engage  in,  directly  or  indirectly,  a financial  transaction  as  a result  of,  or  primarily  relying  on. 
non-public  information  obtained  through  his  official  employment 

h.  Receive  any  salary  or  anything  of  monetary  value  from  a private  source  as  compensation  for  his 
services  to  the  Government. 

i.  Recommend  or  suggest  the  use  of  any  nongovernment  person  or  organization  offering  serv  ices  as 
intermediary,  consultant,  agent,  represenative,  attorney,  expediter,  or  specialist,  for  the  purpose  of 
assisting  in  any  negotiations,  transactions,  or  other  business  with  his  agency 

j.  Knowingly,  and  wilfully,  conceal  or  cover  up  a material  fact,  or  make  any  false  or  fictitious 
statement  in  connection  with  any  official  matter,  document,  or  record. 

k.  Wilfully  and  unlawfully,  conceal,  remove,  mutilate,  falsify,  or  destroy  any  Government 
document  or  record. 

l.  Make  private  promises  of  any  kind  binding  upon  the  duties  of  office,  since  a Government 
employee  has  no  private  word  which  can  be  binding  on  public  duty. 

3.  Contractors  are  prohibited  from: 

a.  Offering  or  giving  gratuities,  such  as  entertainment  or  gifts,  to  any  officer  or  employee  of  the 
Government  with  a view  toward  securing  contracts  or  securing  favorable  treatment  with  respect  to  the 
awarding  or  amending,  or  the  making  of  determinations  with  respect  to  the  performing  of  such  contracts. 
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b.  Knowingly  promising  or  offering  compensation  io  a Governmenl  employee  or  officer  for  any 
services  rendered  by  him. 

c.  Bribing  public  officials,  such  as  giving  or  promising  anything  of  value  to  an  officer  or  employee  of 
the  Government  with  the  intent  to  influence  any  official  act  or  to  influence  such  employee  to  commit  or 
allow  any  fraud  upon  the  Government  or  to  influence  any  such  employee  to  violate  his  lawful  duty. 

d.  Employing  or  retaining  any  person  to  solicit  or  secure  a contract  under  an  agreement  or 
understanding  for  a commission,  percentage,  or  contingent  fee  (except  bona  fide  employees  or  bona  fide 
established  commercial  or  selling  agencies  maintained  by  the  contractor  for  the  purpose  of  securing  the 
pertinent  business). 

e.  Submitting  false  or  fraudulent  claims  or  statements  to  the  Government. 

f.  Submitting  bids  or  proposals  which  have  not  been  arrived  at  independent  from  consultations  or 
agreements  with  competitors  for  the  purpose  of  restricting  competition. 

The  Federal  Procurement  Regulations  and  the  Armed  Services  Procurement  Regulation  state  that  the 
term  "improper  influence”  means  influence,  direct  or  indirect,  which  induces  or  tends  to  induce 
consideration  or  action  by  any  employee  or  officer  of  the  United  States  w ith  respect  to  any  Government 
contract  on  any  basis  other  than  the  merits  of  the  matter. 

There  are  many  areas  not  precisely  covered  by  law  or  regulation  or  contract  clause.  These  are  the  areas 
where  good  judgment  has  to  be  exercised.  For  instance,  common  courtesies  and  amenities  are  not 
gratuities  if  they  are  not  offered  with  a view  of  obtaining  favorable  treatment  in  procurements.  However, 
since  it  is  not  always  possible  to  know  the  intent  of  the  giver  or  the  recipient,  gifts  or  other  favors  even 
though  small  in  value  should  not  be  given  or  offered  to  avoid  embarrassment  or  need  for  explanation.  It  is 
far  more  prudent  to  lean  in  the  direction  of  conservatism  and  prudence.  It  is  emphasized  that  even  the 
appearance  of  trying  to  influence  or  being  influenced  or  the  appearance  of  a possible  conflict  of  interest 
should  be  fervently  shunned. 


CONCLUSION 

What's  happened  to  the  basics?  Not  a thing  They  haven't  vanished  they've  been  with  us  right  along 
It's  whether  we  consciously  apply  them  to  our  problems,  whether  every  training  course  is  introduced  b\ 
them,  whether  we  recognize  in  them  the  roots  of  our  professional  knowledge. 

The  basics  aren't  balloons  of  tokenism.  They  are  the  respectable  pillars  of  procurement 

"But  I have  said  enough  I hope  you  will  treasure  up  the  instructions  I have  given  you.  and  make  them 
a guide  to  your  feet  and  a light  to  your  understanding 
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CALL  FOR  MANUSCRIPTS 


; 


Manuscripts  will  be  considered  for  publication  in  the  Defense  Systems  Manage- 
ment Review.  The  following  topics  are  of  particular  interest  to  the  Review 
readership. 

• Views  of  professionals  on  current  and  pertinent  defense  systems  acquisition 
and  program  management 

• Problems  confronting  Program  and  Systems  Acquisition  Managers 

• Analysis  of  approaches  to  problem  solution 

• Past  experiences  of  responsible  authorities 

• Defense  systems  management  perspectives  of  the  US  Congress, 
the  military  services,  industry,  the  media,  and  multinational 

. programs. 


To  share  your  knowledge  and  expertise  contact  the  Managing  Editor,  Defense 
Systems  Management  Review,  Defense  Systems  Management  College,  Fort 
Bel  voir,  VA  22060. 
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